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 <njs@pobox.com>:
On Thu, Aug 31, 2017 at 8:41 AM, Chris Barker - NOAA Federal
<chris.barker@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