add 'local' as highest precedence architecture for wheel

[dholth]

Sometimes it is useful to be able to build a wheel on the local machine that has a higher precedence than a manylinux wheel. If a certain manylinux wheel is broken, you might compile a non-manylinux wheel on the local machine and place it in a directory on $PIP_FIND_LINKS. Then pip would automatically choose the new wheel without requiring an extra argument per package.

The theory of operation is that the contents of a wheel compiled on the "local" machine are more-specific, from the point of view of that machine, than any other wheel.

These tags are supported after this change, on my machine:

[('cp27', 'cp27mu', 'local'),
 ('cp27', 'cp27mu', 'manylinux2010_x86_64'),
 ('cp27', 'cp27mu', 'manylinux1_x86_64'),
 ('cp27', 'cp27mu', 'linux_x86_64'),
 ('cp27', 'none', 'local'),
 ('cp27', 'none', 'manylinux2010_x86_64'),
 ('cp27', 'none', 'manylinux1_x86_64'),
 ('cp27', 'none', 'linux_x86_64'),
 ('py2', 'none', 'local'),
 ('py2', 'none', 'manylinux2010_x86_64'),
 ('py2', 'none', 'manylinux1_x86_64'),
 ('py2', 'none', 'linux_x86_64'),
 ('cp27', 'none', 'any'),
 ('cp2', 'none', 'any'),
 ('py27', 'none', 'any'),
 ('py2', 'none', 'any'),
 ('py26', 'none', 'any'),
 ('py25', 'none', 'any'),
 ('py24', 'none', 'any'),
 ('py23', 'none', 'any'),
 ('py22', 'none', 'any'),
 ('py21', 'none', 'any'),
 ('py20', 'none', 'any')]

References #6523

[pfmoore]

Looks like some tests are failing ("test_manylinuxXXX_is_first" sounds suspiciously like it's the test that is over-specific :-)). It would probably be worth adding another test, test_local_is_first that explicitly documents and asserts that "local" is always available as the most specific tag.

Apart from test details, I'm +1 on this change.

[xavfernandez]

I would say that PEP 425 (or some other one) would need to be amended first ?

[pfmoore]

Good call. PEP 425 is very vague on the details of valid tags, but as this is a tag with a globally valid meaning (much like "none" and "any") it should be documented as such. If nothing else, that would avoid the interpretation issues that triggered the need for this in the first place.

Side note: IMO PEP 425 could do with a clean-up to clarify as much of the globally common definitions as possible, but I don't think that's something we need to worry about here.

[BrownTruck]

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will be eligible for code review and hopefully merging!

[chrahunt]

Since we're on the verge of getting rid of this part of pep425tags, I'll close this and we can move the discussion over to pypa/packaging#239.