There are two points that I would note here: 1. setuptools handling of environment markers in wheels was actually broken until recently. 2. Even now, people still prefer runtime detection of environment markers to work around pip's upgrade behavior and old setuptools versions. There needs to be a public effort to change this behavior.
For #2, it's really not a clean solution, but it would be more effective to scan the bytecode of setup.py and then warn users that this behavior is deprecated. I expect that you would get a lot of complaints from package authors but that is the point. 2017-08-31 13:03 GMT-05:00 Nathaniel Smith <n...@pobox.com>: > On Thu, Aug 31, 2017 at 8:41 AM, Chris Barker - NOAA Federal > <chris.bar...@noaa.gov> wrote: > > The package manager should manage the package, not built it, or change > it. > > > > 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 > retroactively turned lots of setup.py scripts from working into > broken. The problem is that with this kind of setup.py, setuptools has > *no idea* that the install_requires you gave it would have been > different if you had run setup.py with a different version of Python, > so when it has to assign Python tags to a built wheel it guesses wrong > and uses ones that are too general. > > The right way to do this is to use PEP 508 environment markers: > https://www.python.org/dev/peps/pep-0508/#environment-markers > or the non-standard extras hack: > https://wheel.readthedocs.io/en/latest/#defining- > conditional-dependencies > Both of these let you export the whole requirements-choosing logic > into the wheel metadata, so that it can be evaluated at install time > instead of build time. > > 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. > > Hopefully new legacy-free backends will get this right from the start. > For example flit makes it impossible to get this wrong. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > 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
