I'm not against renaming a wheel to adjust the tags, but it is a strange caching strategy. wheel is due for a 'retag' feature that does a more rigorous job of changing tags.
The build system should name its wheels correctly. Normally the pyNN tag would be used for a pure distribution and the cpNN tag when there are extensions. If you want to affect the tagging when called through PEP 517, edit the source's pyproject.toml / setup.cfg / setup.py. It will probably always make sense to use pip to build wheels when you want to build wheels for a project and all its dependencies. Then you can keep these wheels in a folder for repeatable offline deployment. On Thu, Aug 31, 2017 at 11:48 AM Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > > that neither pip nor the setuptools backend should not change the tags > > it applies to wheels by default). > > I'm a bit confused -- are we talking about the backwards compatible > path to the future -- or the end-game? > > In short -- I'm sure we'll have to do some hacky stuff to keep > backwards compatibility, but the end game should be a clean separation > of concerns : > > Pip (or any front end) should never "build a wheel", and it certainly > shouldn't have to know enough about what's in a wheel to be re-naming > it for generic python vs cpython. > > 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. > > As to using pip to build wheels -- there is good reason to do that > now, but in s post PEP 517 world, one would call the build system > directly to build a wheel-- after all, all pip should be doing is > calling the build system anyway. > > -CHB > _______________________________________________ > 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
