ImportError: No module named pip.pep425tags

[papachoco]

I am getting the exception below when loading extensions in buildout using zc.buildout-2.11.3 and pip 10.0.0

Thanks

Carlos

Got buildout.wheel 0.2.0.
While:
  Installing.
  Loading extensions.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/Users/csanchez/Documents/workspace/nti.dataserver-buildout/eggs/zc.buildout-2.11.3-py2.7.egg/zc/buildout/buildout.py", line 2127, in main
    getattr(buildout, command)(args)
  File "/Users/csanchez/Documents/workspace/nti.dataserver-buildout/eggs/zc.buildout-2.11.3-py2.7.egg/zc/buildout/buildout.py", line 638, in install
    self._load_extensions()
  File "/Users/csanchez/Documents/workspace/nti.dataserver-buildout/eggs/zc.buildout-2.11.3-py2.7.egg/zc/buildout/buildout.py", line 1174, in _load_extensions
    ep.load()(self)
  File "build/bdist.macosx-10.13-x86_64/egg/pkg_resources/__init__.py", line 2324, in load
    return self.resolve()
  File "build/bdist.macosx-10.13-x86_64/egg/pkg_resources/__init__.py", line 2330, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/Users/csanchez/Documents/workspace/nti.dataserver-buildout/eggs/buildout.wheel-0.2.0-py2.7.egg/buildout/wheel/__init__.py", line 9, in <module>
    import pip.pep425tags
ImportError: No module named pep425tags

[mgedmin]

pip 10 moved all of its internal APIs so that people would stop importing them. See this thread: https://mail.python.org/pipermail/distutils-sig/2018-April/032181.html

I think there are going to be at least two steps involved for most projects affected by the API change:

1. The quick fix to add pip 10 compatibility (which is likely a matter of "copy the code you need into the project that needs it")
2. The technical debt reduction to reduce code duplication (which is likely a matter of "add the required APIs to the 'packaging' project")

Step 2 is the step that the pip internals refactoring is designed to encourage, as we believe a lot of tool developers were just using pip's internal APIs rather than filing RFEs and submitting PRs to help guide the evolution of the stable APIs in packaging in a use-case driven manner.

[leorochael]

Curiously, the thing from pip that buildout.wheel needs is exactly the same pip.pep425tags.get_supported() function that Matthew Brett is missing earlier in that thread:

https://mail.python.org/pipermail/distutils-sig/2018-April/032178.html

I expected this would happen when I first heard the announcement.

However, since setuptools learned how to install wheels by itself not long after the last release of buildout.wheel and, consequently, Buildout can work with wheels without buildout.wheel, I think people affected by this issue are better off upgrading setuptools and Buildout, and removing buildout.wheel from extensions.

[sdouche]

Buildout can work with wheels without buildout.wheel, I think people affected by this issue are better off upgrading setuptools and Buildout, and removing buildout.wheel from extensions.

Hi @leorochael. Can you point me the right way to do this? I must install only binary packages and I can't find how to do that w/o the wheel extension.

Thanks.

[mgedmin]

AFAIU it should be happening automatically, if you have sufficiently recent zc.buildout and setuptools versions.

[leorochael]

@papachoco, please try to get to a minimal buildout.cfg that reproduces this issue.

Then try upgrading buildout and setuptools, and removing buildout.wheel from the extensions setting in your buildout.cfg and see if the problem persists. If not, see if your installation was done with wheels.

Unlike buildout.wheel, when Buildout uses setuptools to install wheels natively, they are converted into eggs, so the only way to know that wheels were used in buildout is to run with -v and pay attention to whether a source distribution is being downloaded and built or whether a wheel file was downloaded and unpacked.

We might have to officially deprecate buildout.wheel on Buildout itself, like buildout-versions and buildout.dumppickedversions.

[k4ml]

Tested with latest setuptools and zc.buildout and installing from wheel seem to work - installing lxml is a snap instead of compiling like in old setuptools without buildout.wheel. This also seem to fix #17 and https://github.com/buildout/buildout/issues/407.

[sdouche]

Hi. Tested successfully w/o using the script bootstrap.py ($ pip install buildout then $ buildout in the directory). Why this script still uses ez_setup.py? Do I need to remove definitively this way to launch buildout?

[wiggin15]

Please don't deprecate this project yet. setuptools is still buggy and fails to install some wheels (e.g. https://github.com/pypa/setuptools/issues/1362 and https://github.com/pypa/setuptools/issues/1350). buildout.wheel works correctly. Please fix the problem with the newer pip and keep this project alive.

[leorochael]

@wiggin15, I can relate, but this can only be fixed in buildout.wheel if we can import pep425tags.get_supported() from somewhere canonical. I'd be -1 on any attempt to fish this information from internal pip APIs again.

The first time around, I used pip.pep425tags because it was either that or copying that information somewhere else.

Back then I tried to do the right thing back then by moving pep425tags to packaging (See pypa/packaging#83), but it got bogged down in "trying to design the perfect API" or something.

If you want to see buildout.wheel move forward, then please make sure we can import get_supported() from somewhere... supported....

[leorochael]

Well, it looks like setuptools got tired of waiting and decided to fork pep425tags.

We could provisionally import it from there.

I'd be ok with a PR doing that and removing the pip dependency as, presumably, if pip gets around to moving pep425tags into packaging, then setuptools would just carry it vendored as well.

[masudrehman]

if you want to use module wheel.pep425tags use this wheel version pip3 install wheel==0.34.1