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

Patch packaging to support PEP 703 (--disable-gil) #12635

Closed
wants to merge 4 commits into from

Conversation

colesbury
Copy link

This applies pypa/packaging#728 as a stopgap measure to support the free-threaded builds of CPython. That PR is already merged upstream, but a full upgrade of the packaging library is more complicated due to removal of legacy versions and version specifiers.

See #12634

This applies pypa/packaging#728 as a stopgap
measure to support the free-threaded builds of CPython. That PR is
already merged upstream, but a full upgrade of the packaging library is
more complicated due to removal of legacy versions and version
specifiers.

Closes pypa#12634
@notatallshaw
Copy link
Contributor

notatallshaw commented Apr 17, 2024

I believe vendor patches should be put here: https://github.com/pypa/pip/tree/main/tools/vendoring/patches

I'm not familiar with the mechanism of how they get applied though.

@notatallshaw
Copy link
Contributor

notatallshaw commented Apr 17, 2024

Also, you should be aware of the policy in case you're not already: https://pip.readthedocs.io/en/stable/development/vendoring-policy/ https://pip.pypa.io/en/stable/development/vendoring-policy/

@pfmoore
Copy link
Member

pfmoore commented Apr 17, 2024

Also, you should be aware of the policy in case you're not already: https://pip.readthedocs.io/en/stable/development/vendoring-policy/

The official link is https://pip.pypa.io/en/stable/development/vendoring-policy/ (I think you're quoting the docs from a fork).

@colesbury
Copy link
Author

Thanks for the pointers. A relevant line from the policy is:

Vendored libraries MUST not be modified except as required to successfully vendor them.

I'm not sure what counts as "successfully vendor", but I think a reasonable interpretation would be that a library is not successfully vendored if it prevents pip from working correctly in the free-threaded 3.13 build.

#12300 is clearly a better long term solution -- this is only intended as a stopgap measure. I would like feedback on whether you think this worthwhile.

@pfmoore
Copy link
Member

pfmoore commented Apr 17, 2024

I think it's reasonable to consider doing this. Having said that, the plan is for the upgrade of packaging to be completed for the 24.1 release, so I'd advise that we don't merge this until we know for certain whether that's going to be possible.

@pradyunsg
Copy link
Member

Closing this out since #12300 has merged.

@pradyunsg pradyunsg closed this May 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants