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. That is the challenge! But the motivating use case here was a package with a c extension that was optionally built. That's the rare case. Regular old pure-python packages are the usual case, and a lot easier. -CHB 2017-08-31 16:29 GMT-05:00 Chris Barker <chris.barker@noaa.gov>:
On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith <njs@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.Barker@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig