Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
packaging 16.4 does not allow whitepace between requirement version conditions #502
Comments
bb-migration
commented
Feb 25, 2016
bb-migration
commented
Feb 25, 2016
|
Original comment by AdamChainz (Bitbucket: AdamChainz, GitHub: AdamChainz): +1 failing with |
bb-migration
commented
Feb 25, 2016
bb-migration
commented
Feb 25, 2016
bb-migration
commented
Feb 25, 2016
bb-migration
commented
Feb 25, 2016
|
Original comment by thiefmaster (Bitbucket: thiefmaster, GitHub: thiefmaster): Thanks! |
bb-migration
commented
Feb 25, 2016
bb-migration
commented
Feb 25, 2016
bb-migration
commented
Feb 26, 2016
bb-migration
commented
Feb 27, 2016
bb-migration
commented
Feb 27, 2016
bb-migration
commented
Mar 1, 2016
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): @msabramo, sorry to hear you're having trouble. There are tests in both setuptools and packaging to catch the reported error, so I'm confident it's fixed, though it's possible there's another edge case that wasn't considered. I suspect given that you can't readily replicate the issue that it's environmental. Perhaps you have the latest setuptools but not the latest packaging. Or maybe you have setuptools 20.2.2 metadata and 20.2.1 code. If you find that you're able to replicate a failure with a clean install of setuptools 20.2.2, post back here or file a new ticket (if it's not the same issue). |
bb-migration
commented
Mar 1, 2016
|
Original comment by msabramo (Bitbucket: msabramo, GitHub: msabramo): @jaraco I agree that it's probably an environment problem. I was just able to rebuild the virtualenv and have it work. A few people here bumped into this -- I wonder if it happens when upgrading from setuptools 20.2.1 (was this version deleted from PyPI?) to 20.2.2. |
bb-migration
commented
Mar 1, 2016
bb-migration
commented
Mar 1, 2016
|
Original comment by kudos (Bitbucket: kudos, GitHub: kudos): I'm still seeing this problem with 20.2.2 installing IPython.
|
bb-migration
commented
Mar 1, 2016
|
Original comment by GothAlice (Bitbucket: GothAlice, GitHub: Unknown): Continue to have problems with 20.2.2 in production deployment, against |
bb-migration
commented
Mar 2, 2016
|
Original comment by icordasc (Bitbucket: icordasc, GitHub: Unknown): @kudos @gothalice I can't reproduce this. In a virtualenv:
IPython works just fine. Installing |
bb-migration
commented
Mar 2, 2016
|
Original comment by msabramo (Bitbucket: msabramo, GitHub: msabramo): We were having problems like this too. It seems that the problems might've started with setuptools 20.2.1 and then when we upgraded those virtualenvs to 20.2.2, we still had problems, but then when I rebuilt the virtualenvs with 20.2.2, they seemed to be fine. I wonder if bits of 20.2.1 get left behind even after an upgrade to 20.2.2. |
bb-migration
commented
Mar 3, 2016
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I'm also unable to reproduce the issue, even with installing setuptools 20.2.1 first and upgrading it to 20.2.2. I even tried installing 20.2.1 with pip and then upgrading to 20.2.2 with setuptools, but |
bb-migration
commented
Mar 3, 2016
|
Original comment by jessica_lucci (Bitbucket: jessica_lucci, GitHub: Unknown): We're still seeing this issue with 20.2.2 as well, where the install of our package fails while trying to install futures:
Confirming we're pegged to 20.2.2
Pegging setuptools to 20.1.1 allows install to succeed. |
bb-migration
commented
Mar 13, 2016
|
Original comment by miohtama (Bitbucket: miohtama, GitHub: miohtama): Still with setuptools 20.2.2, IPython and Python 3.5 virtualenved on Ubuntu Linux 14.04: ipython/ipython#9311 It installs cleanly on other machines (OSX), though, so I am not exactly sure what is triggering the issue. Something else beside setuptools version might be in play. It might be that pip, virtualenv and easy_install install setuptools somehow differently and something is left dangling around? |
bb-migration
commented
Mar 14, 2016
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I'm sorry that people are still experiencing this issue. Unfortunately, no one has yet been able to describe a scenario in which the issue can be replicated. Here's me installing and running iPython on Ubuntu 14.04 / Python 3.4.3 in a virtualenv running Pip 8.1.0 / Setuptools 20.2.2 without any problems.
I didn't attempt it using Python 3.5, as Ubuntu Linux 14.04 comes with Python 3.4, and that's probably unrelated to the cause. At this point, the best I can do is apologize, but this issue won't receive any more attention until someone is able to demonstrate the steps necessary to replicate the failure from a clean environment or trace the issue in an environment where it is failing to identify the faulty state. |
bb-migration
commented
Mar 14, 2016
bb-migration
commented
Mar 15, 2016
|
Original comment by miohtama (Bitbucket: miohtama, GitHub: miohtama): Here is my Python 3.5 repeatable test case: Let's start by creating Python 3.5 virtualenv on Ubuntu 14.04 from deadsnakes repo::
Install IPython::
load_entry_point() is busted::
No setuptools in the pip list::
pip cannot upgrade the setuptools::
Let's downgrade setuptools::
Now load_entry_point (ipython) works::
If we upgrade setuptools again to 20.2.2 it doesn't work::
|
bb-migration
commented
Mar 15, 2016
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): Thanks @miohtama . With that, I was able to replicate the issue. At the first stage, where the error first exhibits itself in loading entry points, I find this in the 'metadata.json' for ipython:
In particular, note the 'extras' with strange syntax and mismatched quotes. Something isn't generating that metadata properly. |
bb-migration
commented
Mar 15, 2016
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): Installing the latest iPython seems not to be subject to the error. Also, installing 3.2.3 with
Furthermore, when I download and unzip the wheel, it also seems to have these strange syntaxes in the wheel metadata. I suspect the issue is with the packaging of iPython wheels (and probably other packages wheels).
If on the other hand, I use pip to install from the .tar.gz file (https://pypi.python.org/packages/source/i/ipython/ipython-3.2.3.tar.gz#md5=74138ea620fb828a356d8d02a08ba29c), it builds a wheel and that wheel doesn't have the issue. Therefore, I suspect ipython 3.2.3 was built on a buggy version of wheel and that wheel should be pulled from PyPI. @dstufft Do you recognize this error? Do you know how widespread it might be? |
bb-migration commentedFeb 25, 2016
Originally reported by: drcraig72 (Bitbucket: drcraig72, GitHub: Unknown)
Found in the release of setuptools 20.2.1, which vendors in packaging 16.4. It appears that packaging.requirements.Requirement does not comply with PEP-440's "Whitespace between a conditional operator and the following version identifier is optional, as is the whitespace around the commas.", per https://www.python.org/dev/peps/pep-0440/#version-specifiers. Instead, it fails when there is whitespace.
But it succeeds when the whitespace is removed
Opened the same ticket on packaging at pypa/packaging#65