Replaced all uses of distutils with setuptools

[agronholm]

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.

[codecov]

Codecov Report

Merging #428 (d859302) into main (afc0d5e) will increase coverage by 0.54%.
The diff coverage is 82.92%.

@@            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     

Impacted Files	Coverage Δ
src/wheel/cli/__init__.py	23.52% <ø> (-3.26%)	⬇️
src/wheel/cli/convert.py	38.70% <66.66%> (-0.40%)	⬇️
src/wheel/bdist_wheel.py	49.63% <69.23%> (ø)
src/wheel/_setuptools_logging.py	91.66% <91.66%> (ø)
src/wheel/util.py	100.00% <100.00%> (ø)
src/wheel/wheelfile.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afc0d5e...d859302. Read the comment docs.

[agronholm]

I missed one distutils import in wheelfile.py. Fixing.

[henryiii]

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. flit_core is entirely self contained, I believe. Just a thought.

[agronholm]

Can we rely on ubiquitous PEP 517 support everywhere? That would be a requirement for using flit, yes? Anybody whose systems run python setup.py install or similar would have a bad time. Maybe it's best to ditch setup.py altogether then?

[henryiii]

Packages will need to soon. It would be great if installer was ready - maybe that's the last piece needed? Systems are beginning to get serious about ditching setup.py commands - possibly spurred on by https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html, and possibly by the inclusion of Flit into the PyPA.

[henryiii]

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.

[henryiii]

Adding future annotations works in the wild, it seems. :)

[agronholm]

If you are in the PyPA discord, we just had a bit of discussion in off-topic.

I didn't know there is a PyPA discord server. Where was that announced?

[henryiii]

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.

[henryiii]

Here it is: https://discuss.python.org/t/theres-a-pypa-discord-now

[agronholm]

@jaraco I think this is ready for merging, yes?

[jaraco]

I say go for it!

[agronholm]

Thanks everyone!

[agronholm]

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. flit_core is entirely self contained, I believe. Just a thought.

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.

[henryiii]

flit-core already venders dependencies (only packaging, IIRC)

[pfmoore]

An alternative would be to include a custom in-tree backend. It only has to implement build_sdist and build_wheel, and you could hard-code the files to include and use the wheel API to create the wheel. (That's actually an interesting project - I might look at writing a "self-hosting" backend like this myself...)

[henryiii]

This is how flit-core itself is built (using itself): https://github.com/pypa/flit/blob/main/flit_core/pyproject.toml

[pfmoore]

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 flit-core won't ever use the API from wheel to build wheels, but that seems totally fine to me, for something that is deliberately intended as a "lowest possible level" backend. After all, the whole point in having the standard is that we don't tie people into having to use a single implementation.

[agronholm]

I guess this means that flit-core won't ever use the API from wheel to build wheels

If this is true, then it means I could restore pyproject.yaml for the upcoming release.

[pfmoore]

If you switch to flit for the build backend, then yes, I guess it does.

[agronholm]

I have a PR for that now: #436. Reviews are welcome.

[mayeut]

@gaborbernat, this might break pypa/virtualenv in some corner cases in the future:

• Using --no-setuptools without --no-wheel
• Using a version of setuptools not compatible with wheel (the specifier here is quite old already so, as long as it is the case, shouldn't be much of an issue but if it changes, that might be another story, e.g. a patch version of wheel requires a version of setuptools that's too recent to be considered by periodic updates => virtual environment is broken, wheel is not usable)

IMHO those are really corner cases but I thought I'd give you a head's up.

[gaborbernat]

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.

[agronholm]

Thanks for the update, if this goes ahead we should disallow installing wheel without setuptools in virtualenv

This adds an install dependency of setuptools to wheel, so do you need to do anything?

[gaborbernat]

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.