Skip to content

Conversation

zware
Copy link
Contributor

@zware zware commented Sep 10, 2025

At the moment this is just for UnsupportedConfiguration, but I imagine there may be other errors that could be swallowed in relative safety (for example, maybe any 400-class HTTP errors) if the user opts-in to it.

This is an attempt to find a middle ground between the 6.1.0 and 6.2.0 behavior for repositories that are not exactly PyPI but actually try to be close. This allows a user to explicitly say "I know I'm on shaky ground and am my own" while allowing twine maintainers to say "we tried to tell you" :)

I'm not particularly wedded to any of the names/strings I used; suggestions for something better (or stronger, like --unsupported rather than --lenient) are more than welcome, and I'm happy to adjust to taste.

At the moment this is just for `UnsupportedConfiguration`, but I imagine
there may be other errors that could be swallowed in relative safety
(for example, maybe any 400-class HTTP errors) if the user opts-in to
it.
@woodruffw
Copy link
Member

Hi @zware, thanks for opening a PR!

I'm curious what @sigmavirus24 thinks, but I think I'm personally a soft -1 on adding this for a few reasons:

  1. I don't think most users actually notice warnings instead of hard errors: I suspect that a lot of users are using twine indirectly in a manner that either silently swallows logger.warning outputs or presents them as part of a larger logging context (e.g. a CI console dump) where they're likely to be ignored.
  2. I think this might mislead users into thinking that --skip-existing is supported on third-party indices, when it isn't (and will likely continue to not be, at least until there's a finalized PEP that third-party indices can adhere to that specifies their behavior here). I'm concerned in particular that this might be more misleading than the status quo pre 6.2.0, since we're not adding back the hacks that made --skip-existing work somewhat on third-party indices.
  3. More broadly, I'm concerned that --lenient is a pretty broad option name, and could become a rally point for (unrelated) requests to make twine more lenient in its metadata handling, etc., which IMO is the opposite of the direction twine should be going in (which is being as strict and standards-conformant as possible). This is admittedly a bikeshed over the option name however, which is why I'm putting it last 🙂

(I have some other concerns as well, but I think those are the main ones.)

@sigmavirus24
Copy link
Member

One thing I'll say is that twine today is theoretically pluggable in some ways. As it stands, we have an unadvertised entry-point that someone could write a sub-command to add additional commands to twine with. Honestly, if we had our own config file and not the inherited mess from distutils/setuptools I'd be inclined to say "Instead of supporting with best-effort hacks, folks should write a plugin to match that index's behaviour."

If that were more easily configurable, I'd be inclined to allow that. Especially as it might help to make the authentication bit more pluggable too.

I don't think CLI flags are the solution here, they're the quickest hack that gets us back into a hole. It's quick hacks like we initially accepted that got us here. It's the years of trying to fix those as the 3rd parties broke that compatibility with increasing fervor and frequency and laid the burden at our feet.

In short, I think the best way to give people a way out of the feature removal in 6.2.0 is to:

  1. Make things pluggable (find the right layer to do so, find the right interface, document it, let people develop PyPI plugins for it and move on)
  2. Make the plugin something folks must specify explicitly to work, which to some degree requires us being able to modify the configuration file we use. Fundamentally we don't own that. Furthermore, I'm not inclined to add another file into the mix, regardless of whether we were to add a tool declaration to pyproject.toml or not, we shouldn't need more than one file and requiring more than one is terrible UX to try to solve out of this.

2 is the real blocker here. And no, "Just Detect When To Use a Plugin" is a security nightmare. Folks must explicitly opt-in. And a CLI flag is one way to do this, but we must be able to read it from a config file.

@zware
Copy link
Contributor Author

zware commented Sep 11, 2025

To give some context here, I was surprised to find this morning that my use case was broken1, even though I had already looked at the change to remove the --skip-existing hacks last week and determined that I wouldn't be affected, not realizing that I missed the part where all non-PyPI repositories are unconditionally prevented from even trying to work properly2. My goal here is just to allow some way to attempt to use a non-PyPI repository that does behave like PyPI. For my particular case, I can just remove --skip-existing and live with the logged errors, but that makes me feel bad :)

I can definitely understand the reticence towards this approach, though. It definitely has a hacky feel to it, and I can see not wanting to open the door to making other things "lenient".

What about a different approach, entirely separate from --skip-existing (almost replacing it), allowing the user to explicitly list HTTP response codes to ignore on upload? Still a bit hacky, but that's about the level of change that I have the bandwidth to contribute here.

Footnotes

  1. Fortunately I'm just caching some wheels, so the only effects of my breakage are a few extra CPU cycles and downloads from PyPI.

  2. Where "properly" is currently defined as "like PyPI"

@mrgrain
Copy link

mrgrain commented Sep 11, 2025

not realizing that I missed the part where all non-PyPI repositories are unconditionally prevented from even trying to work properly2

This is my only concern as well. I fully support the removal of hacks. And as an OSS maintainer I can appreciate the extra workload this would add to maintainers, even if it's just closing issues/PRs with a prepared statement.

On other hand, if the goal of the project is to provide support for repositories that behave like PyPI, then maybe a section on the docs page that clearly calls out the issue would be furthering this goal even more. You could just link to it when closing any issues/PRs. If the page lays out the integration requirements, it might also be an easy way to make user go and complain to their commercial providers.

But I'm also supportive of this kind of functionality living in user-land, especially long-term.


On the --lenient option. Thanks for the neat idea. It could probably be a more generic option --ack-risk=commercial-repository or similar. But I can understand concerns of Twine not being called directly.

@zware
Copy link
Contributor Author

zware commented Oct 6, 2025

Closing in favor of #1271.

@zware zware closed this Oct 6, 2025
@zware zware deleted the softer_unsupported_configuration branch October 6, 2025 22:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants