[firesteelrain]

This seems like common sense configuration management 101. If I download v1.2 and it’s been published then it should be considered released and not modifiable. With exceptions for ‘dev’ releases of course. I have never published anything on PyPI but I would expect there is a publish button and finalize (?) optional button that if not checked after 14 days makes it final ?

[akerl_]

Are there any package managers that have that kind of publish/finalize flow?

Every one I’m aware of works either as a one-shot (you have to submit everything in one push) or lets you keep adding new assets forever (other, obviously, than PyPI with the addition of this 14 day wall).

[gred]

In the Java world, Maven has a "publish" step. Published artifacts (groups of files) are immutable, so publish == finalize.

[akerl_]

That’s exactly how individual artifacts are (and were) on PyPI. This change isn’t to artifact immutability, it’s to releases (collections of artifacts)

[gred]

Yeah, I think that's the difference. In Maven, the entire set of files which compose a release is immutable. You can't add to or remove from the set of files once you've published. You have to release a new version if you want to add anything.

[akerl_]

Interesting. I’ve only used Maven-format repos once or twice and always via somebody’s preexisting CI tooling. Is there essentially a “draft” release that you can edit repeatedly before hitting “publish”? Is that draft release visible externally as a pre-release, or only to the author?

[gred]

There is indeed a "draft" release (I think they call it a "deployment"), but AFAIK your choice is then to either publish it or delete it. If you review it and it looks good, you publish it and can't change it thereafter (no changes to files, no adding new files, no removing existing files). If, however, you need to change something in the deployment before publishing it, you have to delete the deployment and create + upload a new "draft" release / deployment (can be same version number, since the previous "draft" wasn't published). AFAIK these "draft" releases are visible only to the author.

[firesteelrain]

Doesn’t that sound bizarre? I have never heard of such a thing. The builds should be immutable

[akerl_]

No?

Again, can you think of any packages managers that have a finalize step like you’re describing?

All the package managers I’m aware of do one of two things:

1. You push once with everything baked in.

2. You push as many things as you want forever.

Python releases can sometimes have many different package files (for example, because each platform can have its own wheel), which makes the first option pretty challenging.

[etbebl]

I'm learning here, but for option 2, besides the security risk, doesn't this create the possibility that users could get a broken/unfinished package any time they're updating to a recently "published" release? The property of releases being atomic seems very important.

[akerl_]

Generally each artifact in the release is atomic, as is (and was) the case here.

You’ll never get served a partially uploaded wheel for amd64 Linux, but somebody could come back a year later and add a 2nd wheel to that release for a different architecture.

[firesteelrain]

My point is adding stuff to an existing version doesn’t make it immutable like it should such as Maven-style