setuptools: [BUG] performance after switching to nspektr / importlib_metadata as cratered
setuptools version
setuptools>=60.8.0
Python version
3.10.5
OS
Arch Linux
Additional environment information
No response
Description
It’s slow…
Expected behavior
It’s not slow.
How to Reproduce
▸ python -m venv venv
▸ . ./venv/bin/activate
▸ python --version
Python 3.10.5
▸ pip install -U pip wheel setuptools
Requirement already satisfied: pip in ./venv/lib/python3.10/site-packages (22.0.4)
Collecting pip
Using cached pip-22.1.2-py3-none-any.whl (2.1 MB)
Collecting wheel
Using cached wheel-0.37.1-py2.py3-none-any.whl (35 kB)
Collecting setuptools
Using cached setuptools-62.6.0-py3-none-any.whl (1.2 MB)
Installing collected packages: wheel, setuptools, pip
Attempting uninstall: pip
Found existing installation: pip 22.0.4
Uninstalling pip-22.0.4:
Successfully uninstalled pip-22.0.4
Successfully installed pip-22.1.2 setuptools-62.6.0 wheel-0.37.1
▸ wget -q https://files.pythonhosted.org/packages/71/39/171f1c67cd00715f190ba0b100d606d440a28c93c7714febeca8b79af85e/six-1.16.0.tar.gz
▸ tar xf six-1.16.0.tar.gz
▸ cd six-1.16.0
▸ time python setup.py -q bdist_wheel
python setup.py -q bdist_wheel 3.71s user 0.05s system 98% cpu 3.809 total
▸ pip install 'setuptools<60.10.0'
Collecting setuptools<60.10.0
Downloading setuptools-60.9.3-py3-none-any.whl (1.1 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 17.1 MB/s eta 0:00:00
Installing collected packages: setuptools
Attempting uninstall: setuptools
Found existing installation: setuptools 62.6.0
Uninstalling setuptools-62.6.0:
Successfully uninstalled setuptools-62.6.0
Successfully installed setuptools-60.9.3
▸ time python setup.py -q bdist_wheel
python setup.py -q bdist_wheel 1.74s user 0.13s system 98% cpu 1.888 total
▸ pip install 'setuptools<60.8.0'
▸ time python setup.py -q bdist_wheel
python setup.py -q bdist_wheel 0.49s user 0.03s system 99% cpu 0.524 total
Output
…
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (19 by maintainers)
Here’s a test:
Which does not pass in
v62.6.0
because the code forgets to activate the egg:Going back to
v60.9.3
, the code is also buggy:v60.7.1
works as expected. But again, I think the onus should be on the package developer to ensuresetup_requires
is consistent. The example should be amended:(which works as expected in
v60.7.1
,v60.9.3
, andv62.6.0
)And
_install_requires
’ code and corresponding calls can just be removed.I use entry points with extras, there’s nothing wrong with that.
I think the check for an entrypoint missing dependency is not strictly necessary, and can be dropped: it’s the package developer responsibility to ensure that
setup_requires
is consistent.It looks like we don’t have a test for this behavior.
OK, so the old code would use
ep.require(installer=self.fetch_build_egg)
. That’s from 2005 (v0.6a0
!), just before adding support forsetup_requires
inv0.6a1
. So again, I’m not even sure it’s needed.