Implement PEP 513

[rmcgibbo]

This PR implements PEP 513 (the manylinux1 PEP approved on distutils-sig last week). The code was written mostly in the PEP by @njsmith. It's implemented as an extra part of pep425tags.get_supported that, when running on Linux, checks if the current machine is manylinux1 compatible if so, adds it to the returned list of supported tags.

[njsmith]

@rmcgibbo: It would be good to also add a check to get_platform like

      platform = distutils.util.get_platform().replace('.', '_').replace('-', '_')
      # for 32-bit python running on a 64-bit kernel, get_platform incorrectly returns linux_x86_64
      # see https://mail.python.org/pipermail/distutils-sig/2016-January/028215.html
      if platform == "linux_x86_64" and sys.maxsize == 2147483647:
          platform = "linux_i686"
      return platform

[rmcgibbo]

@njsmith do you think pip is really the right place for that?

(It's also worth mentioning as a stopgap, that you can get the linux32 behavior by prefixing commands with linux32, for example running linux32 pip ...)

[matthew-brett]

Maybe safer as:

    try:
         import _manylinux
    except (ImportError, AttributeError):
          # Fall through to heuristic check below
          pass
    else:
          return bool(_manylinux.manylinux1_compatible)

[njsmith]

No, this changes the semantics -- the reason it's written that way in the PEP is that it's legal to have a _manylinux module that doesn't define a manylinux1_compatible attribute. (Hence the AttributeError check.)

[Ivoz]

Is there a reason _manylinux is not vendored?

[njsmith]

Yes, _manylinux is basically a config file that may be added to python by a distributor, as a way of providing information about a particular python install to pip. It's not an actual module with, like, code in it. So vendoring it would defeat the purpose :-). See PEP 513 for details.

[njsmith]

The right place is distutils, but distutils is stuck on the cpython release
cycle. And linux32 is great if you know you want it, but the problem with
this bug is that if you ever forget and run pip on an affected system, then
you'll silently get broken libraries installed.
On Feb 3, 2016 3:39 PM, "Robert T. McGibbon" [email protected]
wrote:

@njsmith https://github.com/njsmith do you think pip is really the
right place for that?

(It's also worth mentioning as a stopgap, that you can get the linux32
behavior by prefixing commands with linux32, for example running linux32
pip install...)

—
Reply to this email directly or view it on GitHub
#3446 (comment).

[njsmith]

@rmcgibbo: Looks like you have some pep8 failures

[njsmith]

Remaining Travis failures appear to just be PyPI being flaky.

[pfmoore]

I restarted the ones that had failed.

[rmcgibbo]

Okay, now that the travis checkmark is green, is there anything special I have to do for the "reviewable" hook?

[xavfernandez]

why the is True ?

[njsmith]

I think the only change needed to handle this last round of PEP updates is to delete this unicode check

[njsmith]

My bad -- you also need to remove the maxunicode test :-)

[njsmith]

@rmcgibbo: pep8 failures (and some spurious failures due to pypi flakiness)

[ogrisel]

I addressed the remaining CI failures in #3497.

[rmcgibbo]

Thanks @ogrisel for picking this up while I finished my Ph.D. thesis. I'll close this and we can continue with your PR.