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 <chris.bar...@noaa.gov>: > On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith <n...@pobox.com> 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.bar...@noaa.gov > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
