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.barker@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