Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Installation issue on Python 3.5.1 #40

Closed
blueyed opened this issue Feb 8, 2020 · 7 comments
Closed

Installation issue on Python 3.5.1 #40

blueyed opened this issue Feb 8, 2020 · 7 comments

Comments

@blueyed
Copy link

blueyed commented Feb 8, 2020

With pytest's CI I've noticed that it looks like the latest release causes problems on Python 3.5.1.

Initially:

$ tox
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.1/bin/tox", line 7, in <module>
    from tox import cmdline
  File "/home/travis/virtualenv/python3.5.1/lib/python3.5/site-packages/tox/__init__.py", line 9, in <module>
    import pluggy
  File "/home/travis/virtualenv/python3.5.1/lib/python3.5/site-packages/pluggy/__init__.py", line 16, in <module>
    from .manager import PluginManager, PluginValidationError
  File "/home/travis/virtualenv/python3.5.1/lib/python3.5/site-packages/pluggy/manager.py", line 11, in <module>
    import importlib_metadata
  File "/home/travis/virtualenv/python3.5.1/lib/python3.5/site-packages/importlib_metadata/__init__.py", line 9, in <module>
    import zipp
ImportError: No module named 'zipp'
The command "tox" exited with 1.

With tox -vv: https://travis-ci.org/pytest-dev/pytest/jobs/647622826

Not sure if I'm missing something etc, and if this should be supported/pinned, but wanted to leave it here already.

pytest might just remove 3.5.1 from its CI after all.

(via pytest-dev/pytest#6691 (comment)).

@blueyed
Copy link
Author

blueyed commented Feb 9, 2020

Likely needs an upgrade of virtualenv also for tox I guess.

@blueyed blueyed closed this as completed Feb 9, 2020
@blueyed
Copy link
Author

blueyed commented Feb 9, 2020

The error is:

Collecting zipp>=0.5 (from importlib-metadata<2,>=0.12; python_version < "3.8"->tox)
  Downloading https://files.pythonhosted.org/packages/60/85/668bca4a9ef474ca634c993e768f12bd99af1f06bb90bb2655bc538a967e/zipp-2.2.0.tar.gz
  Running setup.py (path:/tmp/pip-build-joj0um_1/zipp/setup.py) egg_info for package zipp produced metadata for project name unknown. Fix your #egg=zipp fragments.
Collecting pyparsing>=2.0.2 (from packaging>=14->tox)
  Downloading https://files.pythonhosted.org/packages/5d/bc/1e58593167fade7b544bfe9502a26dc860940a79ab306e651e7f13be68c2/pyparsing-2.4.6-py2.py3-none-any.whl (67kB)
    100% |████████████████████████████████| 71kB 10.7MB/s 
Building wheels for collected packages: unknown, unknown
  Running setup.py bdist_wheel for unknown ... done
  Stored in directory: /home/travis/.cache/pip/wheels/a0/1f/9d/d132b3fbc38b33322681e3a7830c0a29fce7f55c3a06b85c65
  Running setup.py bdist_wheel for unknown ... error
  Complete output from command /home/travis/virtualenv/python3.5.1/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-joj0um_1/unknown/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /tmp/tmpr0__u8rxpip-wheel- --python-tag cp35:
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/home/travis/virtualenv/python3.5.1/lib/python3.5/tokenize.py", line 454, in open
      buffer = _builtin_open(filename, 'rb')
  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pip-build-joj0um_1/unknown/setup.py'

(e.g. in https://travis-ci.org/pytest-dev/pytest/jobs/647959521#L482)

Still not sure which bug it is, so I'll leave it for now.

@blueyed blueyed reopened this Feb 9, 2020
@richvdh
Copy link

richvdh commented Feb 9, 2020

I've just been bitten by this (or something very similar) on python 3.5.2. We're still trying to support ubuntu xenial, hence the desire for packages that work there.

It seems the main problem is with the outdated version of pip: xenial ships with pip 8.1.1, which doesn't understand the data-requires-python metadata attributes returned by the pypi index (https://pypi.org/simple/zipp/), and therefore happily attempts to install zipp 2.x versions despite their requires-python:>=3.6 attributes.

Meanwhile, the default version of setuptools (20.7.0 here) doesn't understand the sdist distributions, leading to errors like the one quoted by @blueyed above.

The thing that has changed with this release is that the wheel for zipp 2.2.0 is named zipp-2.2.0-py36-none-any.whl, which contrasts with the wheels for earlier releases in the 2.x series, such as zipp-2.1.0-py3-none-any.whl (note py3 vs py36).

Previously, pip would download and install the wheel for 2.1.0, despite the requires-python attribute. For 2.2.0, pip rejects the wheel (presumably due to the new name), and attempts to install the sdist, leading to the setuptools incompatibility.

So the workaround is to upgrade either or both pip (which will correctly install zipp 1.1.0) or setuptools (which will incorrectly, but without error, allow pip to install the zipp 2.2.0 sdist) before installing.

I'm not really sure if this is a problem that can or even should be solved on the zipp side, although I'd be interested to know what happened in 2.0 to make Python 3.6 a requirement, particularly since it seems a load of people have been using it with 3.5 with apparently no ill effects.

@richvdh
Copy link

richvdh commented Feb 10, 2020

Ah, I probably could have figured most of that out by looking at the relevant PRs (#37, #39).

@blueyed
Copy link
Author

blueyed commented Feb 10, 2020

Note that I had to upgrade pip, setuptools, and virtualenv in the end.
Without virtualenv being upgraded tox would fail with an ImportError for "ensure_text"..

Seems like this is not an issue for zipp though really, closing.

@blueyed blueyed closed this as completed Feb 10, 2020
imphil added a commit to optimsoc/optimsoc-autobuild that referenced this issue Feb 10, 2020
As discussed in
jaraco/zipp#40 (comment), we need
to update pip and setuptools (at least) to get new metadata parsed
correctly and avoid CI errors.
@jaraco
Copy link
Owner

jaraco commented Feb 17, 2020

@richvdh See #42 - it seems there's an issue with devpi where it over-limits based on python version tags. That may have affected you.

@richvdh
Copy link

richvdh commented Feb 18, 2020

that looks like a separate problem (I'm not using devpi, and I'm encountering problems with python 3.5 (and ancient pip)), but thanks for the heads-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants