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

Pipenv install parsing wrong package name #2956

Closed
arruda opened this issue Oct 9, 2018 · 25 comments
Closed

Pipenv install parsing wrong package name #2956

arruda opened this issue Oct 9, 2018 · 25 comments

Comments

@arruda
Copy link
Contributor

arruda commented Oct 9, 2018

Issue description

After the latest patch for the incompatibility problem with pip 18.1, the pipenv parsing of the package name during installation no longer is working (it's replacing . in the package name for a - and this leads to pip not finding the available versions).

This happens with pip 18.1 as well as 18.0.

Expected result

pipenv install zope.interface==4.5.0 should install from this package https://pypi.org/project/zope.interface/

Actual result

Instead it translates to zope-interface==4.5.0 and then it don't find the package:

Could not find a version that satisfies the requirement zope-interface==4.5.0 (from versions: 4.4.0, 4.4.1, 4.4.2, 4.4.3)
No matching distribution found for zope-interface==4.5.0

Steps to replicate

create new virtualenv with latest pipenv version (2018.10.9) to see it break, and test it with the previews one (2018.7.1) where it's still ok.

obs: I'm not sure if this is a bug in pip or pypi (not finding the correct version when replacing . with -), but since it started happening with the latest pipenv release then I believe it is actually related to pipenv.

@encukou
Copy link

encukou commented Oct 9, 2018

This looks related to PEP 503's standardization name normalization. As this is gradually implemented across the ecosystem, things seem to break.

@Jamim
Copy link
Contributor

Jamim commented Oct 9, 2018

One more affected package:

@xocasdashdash
Copy link

Another package is dogpile.cache (Related issue: #2959)

@Jamim
Copy link
Contributor

Jamim commented Oct 9, 2018

The related issue: zopefoundation/zope.interface#124

@xocasdashdash
Copy link

@Jamim does this issue needs to be fixed on each package that has a "." in its name?

@danieljacobs1
Copy link

Another package with a dotted-name which I use: https://pypi.org/project/testing.postgresql/

@Jamim
Copy link
Contributor

Jamim commented Oct 9, 2018

I'm not sure, but it looks like something is wrong with package name normalization at pypi.org (pypa/warehouse).

By the way, this issue could be related: pypi/conveyor#12

@arruda
Copy link
Contributor Author

arruda commented Oct 9, 2018

That's right @Jamim, that what I was unsure about.
Maybe this just pointed up a spot light in a unknown pypi bug... and if so, what should be the best course of action here. To patch up pipenv so that it keeps working with a broken pypi or to wait until pypi has fixed all the broken packages that fall on this list.

@Jamim
Copy link
Contributor

Jamim commented Oct 9, 2018

@arruda I prefer to have an option, e.g. env variable PIPENV_NORMALIZE_NAMES that you could set to 0 to disable the corresponding normalization feature of pipenv.

@immerrr
Copy link
Contributor

immerrr commented Oct 9, 2018

@Jamim pipenv has to normalize names internally. You might have packages A depending on "zope.interface" and B depending on "zope-interface", both being valid package names and installable separately. pipenv's dependency resolution must normalize things, because otherwise you can end up with separate "zope-interface" and "zope.interface" dependencies in Pipfile.lock.

@Jamim
Copy link
Contributor

Jamim commented Oct 9, 2018

@immerrr Yep, you are definitely right.
But we still need to have a workaround until PyPI is not fixed.
So, I suppose that my suggestion is still valuable.

@immerrr
Copy link
Contributor

immerrr commented Oct 9, 2018

pip bug: pypa/pip#5870

@palnabarun
Copy link

Another package that is affected is web.py

I even filed an issue here. pypi/warehouse#2951

@jakeczyz
Copy link

zc.lockfile is another example (putting here in case others google for it, specifically). Any workaround suggestions?

@immerrr
Copy link
Contributor

immerrr commented Oct 10, 2018

@jakeczyz it was mentioned that downgrading pipenv to 2018.7.1 worked

@svenpanne
Copy link

I am not sure if this is really fixed for all cases, see e.g. pypi/warehouse#2849. That issue is about pipenv clean, not pipenv install. Should I open a new issue for that case or should the issue in this thread be re-opened?

@svartkanin
Copy link

svartkanin commented Oct 11, 2018

I also still get an error when installing recurly which has backports.ssl-match-hostname as a dependency but gets resolved to backports-ssl-match-hostname.

@uranusjr
Copy link
Member

@svenpanne I don’t believe that is the same issue. pip uninstall is able to handle canonicalised package names.

@svenpanne
Copy link

I also still get an error when installing recurly which has backports.ssl-match-hostname==3.5.0.1 as a dependency but gets resolved to backports-ssl-match-hostname==3.5.0.1.

Hmmm, this works for me with the current master. Perhaps related to the Python version? I'm using 2.7.15.

@uranusjr
Copy link
Member

Or it might be the cache. Try pipenv --clear.

@svartkanin
Copy link

svartkanin commented Oct 11, 2018

pip install pipenv --upgrade
...
pip --version 
pip 18.1

pipenv --version
pipenv, version 2018.10.9

pipenv install --dev
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead. You can set PIPENV_VERBOSITY=-1 to suppress this warning.
Installing dependencies from Pipfile.lock (917af8)…
An error occurred while installing backports-ssl-match-hostname==3.5.0.1 --hash=sha256:502ad98707319f4a51fa2ca1c677bd659008d27ded9f6380c79e8932e38dcdf2! Will try again.
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 185/185 — 00:00:31
Installing initially failed dependencies…
Collecting backports-ssl-match-hostname==3.5.0.1 :00

  Could not find a version that satisfies the requirement backports-ssl-match-hostname==3.5.0.1 (from -r /tmp/pipenv-rya05p93-requirements/pipenv-5zo1fv20-requirement.txt (line 1)) (from versions: )
No matching distribution found for backports-ssl-match-hostname==3.5.0.1 (from -r /tmp/pipenv-rya05p93-requirements/pipenv-5zo1fv20-requirement.txt (line 1))

  ☤  ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/1 — 00:00:00

@svenpanne
Copy link

OK, that explains the difference we are seeing: The last released version doesn't contain the relevant fix, I installed directly from github:

sudo -H pip install -U git+https://github.com/pypa/pipenv

@HAnthonyHoyt
Copy link

This bug is actually adversely affecting me in a major way. I've had to update a ton of continuous integration jobs to reference the previous version to prevent this bug from failing all my deploys and deliveries. Please release a fix for this soon.

@mplovepop
Copy link

For anyone else tripping across this, I changed my Dockerfile to:

pip install pip==18.0 && pip install pipenv==2018.7.1

In order to pin pipenv itself.

hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to hroncok/naucse.python.cz that referenced this issue Oct 12, 2018
encukou pushed a commit to pyvec/naucse.python.cz that referenced this issue Oct 12, 2018
hroncok added a commit to cvut/naucse.python.cz that referenced this issue Oct 17, 2018
s-pace pushed a commit to algolia/docsearch-scraper that referenced this issue Nov 2, 2018
s-pace pushed a commit to algolia/docsearch-scraper that referenced this issue Nov 2, 2018
s-pace pushed a commit to algolia/docsearch-scraper that referenced this issue Nov 7, 2018
s-pace pushed a commit to algolia/docsearch-scraper that referenced this issue Nov 7, 2018
@taidinh-tiki
Copy link

Is this issue fixed, I want to add dogpile.cache in my requirements.txt file but it not working, please help

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