Restrict publishing new artifacts to releases after 14 days#19727
Restrict publishing new artifacts to releases after 14 days#19727sethmlarson wants to merge 1 commit intopypi:mainfrom
Conversation
872a899 to
c80d3fb
Compare
|
|
||
| # Check if the release should be closed to | ||
| # new artifacts due to age. | ||
| if not is_new_release and release.created is not None: |
There was a problem hiding this comment.
Note, you can sort of get around this by deleting the release and recreating it.
That's a heavy hammer though, as you won't be able to re-upload files with the same name again, but that's trivial to work around in the wheel case, but sdists are much harder.
There was a problem hiding this comment.
Hmm, this is good to know. I didn't realize we did hard deletes of Release for user-triggered deletes. Any suggestions how to implement this without creating another database model?
Not to leave a trap for us later for when this changes, but API tokens today don't allow deleting releases, so in a way it's still effective against token compromises.
There was a problem hiding this comment.
Thinking about this more, sdists might not be much harder. I know that most of the tooling normalizes versions, but I don't recall if the filename check on PyPI normalizes versions or not. If it does not, then working around it for sdists would be easy too, you just modify your filename to add a .0 to the version and upload that.
Different filename (assuming we don't normalize), so it'd be allowed, but all the consuming tooling will treat it as equivalent.
To answer your question. I don't think there is a way without adding another database model. That's what I had to do for the filename registry, and I can't think of a different option for releases. We don't have soft deletes in PyPI, so deletion is "real", including deleting the whole project and recreating it. Anything that we want to survive past that has to be on a different table that is setup not to cascade on delete (and otherwise handles deletions somehow-- often times by not using foreign keys / relational data but using the "natural" key and manually querying the model to see).
Closes #19726