I don't buy the argument that pip needs to keep separate caches for
different implementations. According to the wheel specification, a wheel is
valid for the Python implementations that it specifies. This is therefore a
blatant violation by setuptools of an existing specification that, in
theory, should be ignored by pip.
That said, setuptools is currently the de facto build system, meaning that
we cannot simply break the status quo. So here's my proposal:
1. For now, wheels are renamed if and only if the backend is setuptools.
2. In the future, we introduce a new setup() function that is imported from
a different module path that requires compliance with the specification.
3. Once the vast majority of projects are using the new setup function, we
can adjust the pep 517 setuptools build backend to use the most restrictive
tag for the old function
4. We can finally remove autobuilding from pip.
One thing to keep in mind is that there are quite a few projects on pypa
with pure python source distributions uploaded that will not be updated and
people may still desire to use. We want pip to be able to still build and
install them.
2017-08-31 16:29 GMT-05:00 Chris Barker
On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith
wrote: Surely the build system should know how to correctly name the wheel it builds.
It's probably worth mentioning the specific problem that motivated pip to start doing this.
It used to be standard, and is still quite common, for setup.py scripts to contain stuff like:
install_requires = [...] if sys.version_info < (3, 4): install_requires += [...] if platform.python_implementation() == "PyPy": install_requires += [...]
setup(..., install_requires=install_requires)
This kind of logic in setup.py worked fine in the old days when all you did was 'setup.py install', but then wheels came along
And indeed, setuptools originally used easy_install, which was part of setuptools...
and
retroactively turned lots of setup.py scripts from working into broken. The problem is that with this kind of setup.py,
But it will take a while for existing setup.py files transition to using those, and in the mean time pip can't assume that a random wheel generated by 'setup.py bdist_wheel' has accurate Python tags.
This was my original point -- I understand that we want "pip install" to continue to work for, hopefully, everything it works for now.
But I do think we should be clear about what is a hack for backward compatibility, and what is part of the designed functionality.
Sorry to be poking at all this from the fringes (Not having been all that involved in a very long discussion), it's just that the whole
distutils--setuptools--pip--distribute--setuptools--pip
stack has a LOT of legacy cruft, and I'm concerned that the efforts for backward compatibility may end up leading us to another poorly de-coupled design.
Hopefully new legacy-free backends will get this right from the start.
exactly -- let's keep the "backward compatibility hack" labels clear!
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig