-
Notifications
You must be signed in to change notification settings - Fork 150
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
Replaced all uses of distutils with setuptools #428
Conversation
Distutils has been deprecated and will be removed in Python 3.12.
The sysconfig.get_platform() and distutils.util.get_platform() functions return "linux-x64_64", not "linux_x64_64" which the previous code and tests assumed.
Codecov Report
@@ Coverage Diff @@
## main #428 +/- ##
==========================================
+ Coverage 67.03% 67.57% +0.54%
==========================================
Files 11 12 +1
Lines 904 916 +12
==========================================
+ Hits 606 619 +13
+ Misses 298 297 -1
Continue to review full report at Codecov.
|
I missed one distutils import in |
Setuptools will now always be present so this is pointless. The pkg_resources module was never imported here anyway.
…ug/warning levels to logged messages. Fixed missing f-string for 'wheelfile_path'.
Not for right now, but would using pypa/flit instead of setuptools be better? I know a few other tools are planning on switching (packaging IIRC?), and that would get rid of the chicken/egg problem and allow a pyproject.toml file again. |
Can we rely on ubiquitous PEP 517 support everywhere? That would be a requirement for using flit, yes? Anybody whose systems run |
Packages will need to soon. It would be great if |
Here's the discussion I was remembering: https://discuss.python.org/t/debundling-the-next-pip-release-will-require-handling-pyproject-toml-based-build-backends/12329 packaging and build likely will make the switch at some point in 2022. If you are in the PyPA discord, we just had a bit of discussion in off-topic. |
Adding future annotations works in the wild, it seems. :) |
I didn't know there is a PyPA discord server. Where was that announced? |
I think there's a discuss.python.org about it? There's a badge in the readme here: https://github.com/pypa/setuptools. The PyPA projects are encouraged to add badges and request channels. There's a "nice" URL for it, but I don't remember what it is. |
@jaraco I think this is ready for merging, yes? |
I say go for it! |
Thanks everyone! |
My plan is to have every packaging back-end depend on wheel after the public API is released. That would mean that the back-end wheel itself uses would have to vendor wheel. That's a bummer, but I can't immediately think of a way around that. |
flit-core already venders dependencies (only packaging, IIRC) |
An alternative would be to include a custom in-tree backend. It only has to implement |
This is how flit-core itself is built (using itself): https://github.com/pypa/flit/blob/main/flit_core/pyproject.toml |
Oh cool! I hadn't realised flit had done that (yet). I knew they had been doing some work on bootstrapping, but not that they'd separated the build backend out totally. I guess this means that |
If this is true, then it means I could restore |
If you switch to flit for the build backend, then yes, I guess it does. |
I have a PR for that now: #436. Reviews are welcome. |
@gaborbernat, this might break pypa/virtualenv in some corner cases in the future:
IMHO those are really corner cases but I thought I'd give you a head's up. |
Thanks for the update, if this goes ahead we should disallow installing wheel without setuptools in virtualenv. A perhaps in that sense at that point in time would be welcome, but indeed is an edge case. |
This adds an install dependency of setuptools to wheel, so do you need to do anything? |
Of course, virtualenv provisions seed packages that until today have no dependencies. If you're adding dependencies now virtualenv needs to make sure they are satisfied post provision. This adds a whole new complexity to the project. We've had this discussion when you added packaging dependency to the project a while back. |
This gets rid of any (direct) distutils dependencies by relying on setuptools instead. It does mean we depend on setuptools as an install dependency but I don't see that as a problem.