Repository navigation
Make setuptools optional at runtime. - #8476
Conversation
This is a mechanical change trying to move stdlib distutils use onto setuptools.distutils.
As title.
| from setuptools import distutils as dutils | ||
| dir_util = dutils.dir_util | ||
| log = dutils.log |
There was a problem hiding this comment.
why not like this?
| from setuptools import distutils as dutils | |
| dir_util = dutils.dir_util | |
| log = dutils.log | |
| from setuptools.distutils import dir_util, log |
There was a problem hiding this comment.
Thanks for taking a look. The issue is:
>>> from setuptools.distutils import dir_util, log
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'setuptools.distutils'
There was a problem hiding this comment.
I see, it’s a not really a submodule, it’s a re-export.
But since setuptools just directly imports distutils, what’s the advantage of importing it from there instead of just doing import distutils?
If the intention is to to not import distutils because it’s deprecated, you need to actually remove the import instead of importing the same thing using a more roundabout path. Should be easy enough, there doesn’t seem to be any good reason to import either symbol from it: log is just a logging.Logger (you can just use another logger I guess) and dir_util.mkpath(...) provides the same functionality as pathlib.Path(...).mkdir(parents=True, exists_ok=True)
There was a problem hiding this comment.
These are good points, thanks for raising them.
I see, it’s a not really a submodule, it’s a re-export.
But since
setuptoolsjust directly importsdistutils, what’s the advantage of importing it from there instead of just doingimport distutils?
I was looking to use the setuptools vendored distutils but think I have done this incorrectly. It's probably setuptools._distutils.
If the intention is to to not import
distutilsbecause it’s deprecated, you need to actually remove the import instead of importing the same thing using a more roundabout path. Should be easy enough, there doesn’t seem to be any good reason to import either symbol from it:logis just alogging.Logger(you can just use another logger I guess) anddir_util.mkpath(...)provides the same functionality aspathlib.Path(...).mkdir(parents=True, exists_ok=True)
This patch is trying to do the absolute minimum necessary to make pycc not use distutils and instead use setuptools's internal copy, and then to make sure that setuptools an optional runtime dependency. Given pycc is scheduled for deprecation in the next Numba release (xref: #8509), I'm not sure that it is worth spending time on finding a full replacement for distutils, then writing and testing it, though can probably make the changes RE: log and mkpath as noted.
|
This pull request is marked as stale as it has had no activity in the past 3 months. Please respond to this comment if you're still interested in working on this. Many thanks! |
|
Feels like this was simply forgotten by the maintainers. @stuartarchibald is it ready? |
@flying-sheep thanks for raising this. It's on the "housekeeping" list for Numba 0.57 (#8762). It's a relatively isolated change and perhaps a lower risk item so hasn't been a high priority whilst other more concerning things have been de-risked e.g. Python 3.11 support. Will hopefully get to this soon! |
|
After having experienced some pain in conda-forge around Setuptools 66, would just like to voice my support for this and any other change that makes us less reliant on Setuptools |
|
I've manually tested this on py3.11 branch. Looks ok. |
|
This patch now conflicts with main due to the py3.11 branch merge. |
Resolved conflicts in: numba/pycc/__init__.py numba/pycc/platform.py numba/tests/support.py numba/tests/test_pycc.py
ce5aa59 resolves. |
| dir_util = dutils.dir_util | ||
| log = dutils.log |
There was a problem hiding this comment.
Suggestion: move the assignments below all import for flake8
|
I've marked this as ready for review, this is with view of getting the code changes merged. Will open another PR that's built on top of this that handles packaging, CI, docs etc. |
sklam
left a comment
There was a problem hiding this comment.
Code changes look good. As noted in previous comment by OP, non-code changes will go in a different PR.
|
Thanks all! 🙏 |
This is a mechanical change trying to move stdlib distutils use onto setuptools.distutils.