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

Adopt bdist_wheel from pypa/wheel #3908

Closed

Conversation

abravalheri
Copy link
Contributor

@abravalheri abravalheri commented Apr 24, 2023

Summary of changes

pypa/wheel maintainers previously described that the long term vision is to transfer bdist_wheel directly to setuptools.
This PR attempts to do that based on the previous changes (that untangled the way Setuptools produced core-metadata and dist-info from pypa/wheel).
It also relies on the WheelBuilder as introduced in a previous PR (the pypa/wheel APIs for building wheel files are likely to change in the future).


This is part of a series of PRs:

The motivation for this series of PRs is the following:


Pull Request Checklist

@abravalheri
Copy link
Contributor Author

abravalheri commented Jun 6, 2023

Hi @agronholm, after reading some previous comments about bdist_wheel I assumed that there is an overall long term intent to move bdist_wheel to the setuptools project. That is what motivated this PR.

I had a look on the pypa/wheel codebase and noticed that macosx_libfile seems to only be used to support bdist_wheel. Am I correct in assuming that macosx_libfile would also be moved to setuptools together with bdist_wheel?

@agronholm
Copy link
Contributor

The macosx_libfile module is used to extract architectural information from macos dynamic libraries in order to determine the appropriate tags for binary wheels. It could conceivably be needed outside of setuptools, if other packaging back-ends start using the new public API.

@abravalheri
Copy link
Contributor Author

abravalheri commented Jun 6, 2023

Thank you very much for the clarification @agronholm.

We might do the transition in 2 steps then... In the first step we bundle macosx_libfile inside setuptools. Then in a second step, we can use it directly from wheel when it is exposed via a public API. Does that sound good?

@agronholm
Copy link
Contributor

Yeah, you'd have to vendor all the necessary modules from wheel in the first step. I think we'd need to coordinate this so as to minimize any duplication between setuptools and wheel. What's the intended time table for this?

@abravalheri
Copy link
Contributor Author

abravalheri commented Jun 6, 2023

I don't have a timeline for this yet. It is a complex change, so I tried to split it up in many smaller steps (e.g., fixing PKG-INFO, removing uses of private pypa/wheel APIs, etc ...). I am hopping that the other maintainers/members of the community will have sometime to have a look on the proposed PRs and give some feedback at some point.

Maybe on the second semester when I have a bit more time, I might start pushing a little more.
What I had in mind is:

  1. Collect feedback about the proposed changes and implement all related modifications.
  2. Publish a beta release and ask for beta testers on the Packaging topic in the Python discourse.
  3. Implement eventual fixes
  4. Create the final release (major version bump).

@abravalheri
Copy link
Contributor Author

The main idea was to get setuptools out of the way for pypa/wheel to advance the works on the public API without risking breaking existing packages. Then later come back and check for opportunities to use this public API and simplify setuptools code base.

@agronholm
Copy link
Contributor

I have been wondering if it makes any sense for all the PyPA stuff to be split between so many different projects. Maybe the wheel related code should be moved to packaging instead?

@abravalheri
Copy link
Contributor Author

I have nothing against this change... For example, it seems that the contents macosx_libfile and other functions to calculate tags could be useful there.

If the packaging maintainers are happy to absorb some functionality that would also be a good alternative1.

Footnotes

  1. I am assuming that bdist_wheel would still be part of setuptools, since it makes more sense.

@agronholm
Copy link
Contributor

Yeah, I think it would be nice if the new public api for wheel would be implemented in packaging instead, and wheel itself was reduced to nothing more than a command line tool. bdist_wheel needs to be migrated to setuptools in any event. The only reason the code still lives in the wheel package is of course historical.

I think I'll open an issue with packaging to discuss this. Then there's a question of whether auditwheel and wheel should be merged together, but I think that's a separate issue.

@agronholm
Copy link
Contributor

pypa/packaging#697

… about unset config variables and potentially wrong Python ABI.
@abravalheri abravalheri marked this pull request as draft March 5, 2024 12:07
@abravalheri abravalheri deleted the dev/adopt_bdist_wheel branch May 22, 2024 15:03
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.

2 participants