Don't publish if version already exists

[claytonlemons]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Let's say a package maintainer publishes version 1.5.0 of package foo. Later on, the maintainer decides to publish new changes but forgets to bump the package version. Now, mayhem and chaos ensue whilst the fabric of reality disintegrates from the epicenter of PyPI.

Ok, so maybe the fabric of reality wont disintegrate, but overwriting an existing package in a remote repo certainly isn't desirable is most circumstances. Would it be possible to add a check/flag to poetry publish such that it errors if a version of a package already exists in a remote repo? Here are some possible API ideas:

Idea 1:

# Assume foo-1.5.0 already exists in the remote repo
poetry publish  # this will error if foo-1.5.0 is published 
poetry publish --force  # this will overwrite the existing foo-1.5.0

Idea 2:

# Assume foo-1.5.0 already exists in the remote repo
poetry publish  # this will overwrite the existing foo-1.5.0
poetry publish --check-existing  # this will error if foo-1.5.0 is published 

Idea 3:

# This lists all the existing versions of the package in the remote repo.
# Clients can then consume the output however they wish to determine if a version already exists.
# The `version` command admittedly may not be the best place for this new functionality, but it's just an example.
poetry version --list-remote

Idea 3 may be useful for reasons other than version checking.

Let me know if any of these ideas sound feasible and worthwhile. I'm happy to submit a PR.

[sinoroc]

I am confused... The issue you are describing should not have happened to begin with. As far as I know it is impossible to overwrite a distribution (sdist or wheel) on PyPI.

Would you mind describing again what happened?
(Not the part where the fabric of reality disintegrated :D)

[claytonlemons]

Would you mind describing again what happened?

@sinoroc The problem that originally motivated this request happened when using Artifactory as the remote repo. I published new changes to a package using an old version that had already been published. A colleague tried to pip install --force-reinstall to get the new changes, but for some reason that wouldn't work. Even clearing the pip cache and recreating the venv would not allow him to get the new changes. However, others, including myself, we are able to install the old version and still get the new changes. Clearly, there was something different about my colleague's setup that prevented him from getting the new changes. However, the lesson we learned was to not overwrite package versions.

As far as I know it is impossible to overwrite a distribution (sdist or wheel) on PyPI.

Ah, I did not know that! I assumed PyPI and Artifactory had similar behavior in this regard. Upon further research, it appears that Artifactory has permissions that control package overwriting. I think that would be a better solution.

[sinoroc]

As far as I know it is impossible to overwrite a distribution (sdist or wheel) on PyPI.

Ah, I did not know that! I assumed PyPI and Artifactory had similar behavior in this regard. Upon further research, it appears that Artifactory has permissions that control package overwriting. I think that would be a better solution.

I did not know Artifactory allowed overwriting an already published distribution (we all learned something). It seems dangerous to me, I am glad it is not the case in PyPI. But for a private internal repository, why not.

I do not know if it is a workflow that poetry wants to support explicitly. It seems like everything is already working as expected. If overwriting is allowed, it overwrites. If it is not allowed, it fails.

If it were my place to decide, I would not change anything, or I would need some further convincing. We'll see what others think.

[claytonlemons]

If it were my place to decide, I would not change anything

Agreed. The status-quo appears to be that it's on the onus of the repo to control overwrites. I'm fine if we close this issue, but other may have a different opinion.

[nikaro]

It would still be nice to have a flag allowing to not fail if the version already exists. I have a use case where my CI run at each commit, even the "publish" step, and i was hoping that poetry would skip publish if version was not incremented from what is on PyPI.

Can this issue be reopened? Or should i open a new one?

[codie3611]

It is the responsibility of the repo to control overwrites but it is the responsibility of the tooling how to handle this case. For some it is an error and for some it is not, thus an option to control the behavior makes very much sense.

[heavelock]

Another use of flag such as --check-existing could be in CI pipelines. It could be used just as a automation step to remind about bumping the version before publishing.

[antaradas94]

This would be really helpful, Something that also helps to overwrite the existing package as well.

[martimors]

twine has the --skip-existing flag, would probably be trivial for Poetry to implement the same?

[radoering]

It has already been done: #2812. You can try with poetry >= 1.2.0b2

[Rusteam]

twine has the --skip-existing flag, would probably be trivial for Poetry to implement the same?

Can we implement this feature?

Another use of flag such as --check-existing could be in CI pipelines. It could be used just as a automation step to remind about bumping the version before publishing.

We too need for CI/CD. In our scenario, we have a jfrog artifactory running for an internal pypi-index and we build our packages with Gitlab CI/CD and the best way to make sure people bump project version is to add this flag.

We would be willing to submit a PR for this if approved.

[neersighted]

Poetry has had --skip-existing for several versions now. If you want a different feature, please open a new issue.

[Rusteam]

I mean to add a --check-exiting option that will fail the command if a version already exists in a package index

[neersighted]

I don't think Poetry is an appropriate tool for such a task (checking if a version exists on an index), though that's mostly because the implementation for the flag would essentially be an entirely separate function that doesn't upload anything, but instead actually implements a (really minimal) PEP 508 client.

Regardless, that's a new feature request; you won't get any traction adding comments to closed & tangential issues -- would you mind creating one?

[Rusteam]

thanks, I'll look into implementing a poetry-plugin for this scenario

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.