Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

24.3 release uses unreleased vendored packaging, breaking devendored systems #13053

Open
1 task done
mgorny opened this issue Oct 28, 2024 · 4 comments
Open
1 task done
Labels
project: <downstream> When the cause/effect is related to redistributors type: bug A confirmed bug or unintended behavior
Milestone

Comments

@mgorny
Copy link
Contributor

mgorny commented Oct 28, 2024

Description

The 24.3 release of pip started using ios_platforms which are not a part of any release. This is in violation of the vendoring policy, and makes it impossible to run new pip with dependencies devendored.

Expected behavior

pip using a released version of packaging.

pip version

24.3

Python version

n/a

OS

Gentoo Linux amd64

How to Reproduce

  1. Devendor dependencies according to pip/_vendor/vendor.txt.
  2. Try to run pip.

Output

No response

Code of Conduct

@mgorny mgorny added S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior labels Oct 28, 2024
@sbidoul sbidoul added this to the 24.3 milestone Oct 28, 2024
@ichard26 ichard26 added project: <downstream> When the cause/effect is related to redistributors and removed S: needs triage Issues/PRs that need to be triaged labels Oct 29, 2024
@ichard26
Copy link
Member

ichard26 commented Oct 29, 2024

Hi, sorry about the breakage here. This wasn't intentional, although was definitely an oversight on our part.

The path forward here would be either:

  • Revert the PR and wait until the local patches are upstreamed in a published release of packaging
  • Modify pip's source to gracefully handle a non-patched packaging (i.e. if this import fails, silently drop iOS support)

I'd prefer reverting the PR for simplicity and to bring pip closer into with the vendoring policy. OTOH, at a glance, option 2 would only involve a small tweak. And I guess it could be more disruptive to rip out a nontrivial change in a bugfix release. Thoughts @sbidoul?

Finally, I do think we need to follow our vendoring policy more strictly, while it is possible to use unreleased versions of libraries without breaking downstream, this seems likely to be a minefield (where we'd inevitably screw up). Otherwise, the policy needs to be reworded to permit non-essential patches that only fail gracefully when the patched libraries are replaced.

@freakboy3742
Copy link
Contributor

Author of the original patch here.

I'd argue there's another possible fix here - work with/encourage packaging to publish a new release. It's been 5 months since packaging has made a release, so one would seem due (given the historical release cadence).

FWIW, reverting would also be disruptive to my own efforts to get PEP 730 support in the broader Python ecosystem; so I've provided #13057 as an import-based workaround for the problem.

@mgorny
Copy link
Contributor Author

mgorny commented Oct 29, 2024

I don't think reverting is really necessary. I think a new release of packaging would be best, with graceful fallback being the second best.

@pradyunsg
Copy link
Member

I should be able to cut a packaging release sometime in the coming days (it's past midnight where I am right now, but I should be able to cut one tomorrow depending on how jet lag treats me).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
project: <downstream> When the cause/effect is related to redistributors type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants