Add opt-in support for --skip-existing on non-PyPI repositories

[John-P]

I'd love to be able to easily test upload workflows locally using tools like pypiserver via testcontainers, or test against third-party registries like Artifactory or Nexus. Unfortunately, this isn't currently possible because --skip-existing is hardcoded to only work with PyPI and TestPyPI URLs.

I totally understand why this restriction was added in #1253 - third-party registries kept changing their error messages and breaking things. But it also makes it hard to test tooling and CI/CD pipelines without hitting production PyPI, which isn't ideal.

What I'm Proposing

Add an opt-in flag --skip-existing-non-pypi (and corresponding TWINE_SKIP_EXISTING_NON_PYPI environment variable) that lets users explicitly enable --skip-existing for non-PyPI repositories.

This would allow:

• Testing locally, e.g. with pypiserver via testcontainers
• Supporting registries that implement PEP 694 by returning status code 409 (I know the JFrog/Artifactory team is interested in aligning with this)

Adding a flag:

• Is opt-in only: Default behaviour unchanged - you have to explicitly enable it
• Adds no new hacks: Doesn't add any brittle string-matching logic. Just allows the existing 409 status code handling (which is what PEP 694 standardizes) to work for non-PyPI repos

Related Context

• #1251 - The Artifactory issue that led to the restriction
• #1253 - The PR that added the restriction
• PEP 694

I'd really appreciate being able to test skip existing with other registries. I understand my proposed flag is perhaps a little verbose and would love to hear suggestions of a better approach.

[woodruffw]

Did you see the discussions in #1270 and #1271? I think we're unlikely to re-add any escape hatches here, because it's a slippery slope back towards to the pile of hacks that previously existed.

My strong preference here would be for a standards-driven approach or for a proposal that uses twine's plugin architecture. I think a CLI option is unfortunately probably a non-starter.

[John-P]

Thanks @woodruffw, looks like I missed those two discussions. That is unfortunate. It is a bit of a pain at the moment. I think quite a few workflow which relied on skip-existing are broken now. I suppose the only way to work around this in the meantime is maintaining a fork or some custom workaround by checking the simple API before trying to publish.

I'll look in to the plugin architecture.