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

pip crashes with IndexError #1107

Closed
alex opened this issue Aug 4, 2013 · 10 comments
Closed

pip crashes with IndexError #1107

alex opened this issue Aug 4, 2013 · 10 comments
Labels
auto-locked Outdated issues that have been locked by automation
Milestone

Comments

@alex
Copy link
Member

alex commented Aug 4, 2013

No idea what causes this, happy to take any steps to assist in reproducability:

(bb85a16c10916f30)Alexanders-MacBook-Pro:bb85a16c10916f30 alex_gaynor$ pip install --download=. colorama
Downloading/unpacking colorama
Cleaning up...
Exception:
Traceback (most recent call last):
  File "/Users/alex_gaynor/.virtualenvs/bb85a16c10916f30/lib/python2.7/site-packages/pip/basecommand.py", line 134, in main
    status = self.run(options, args)
  File "/Users/alex_gaynor/.virtualenvs/bb85a16c10916f30/lib/python2.7/site-packages/pip/commands/install.py", line 236, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/Users/alex_gaynor/.virtualenvs/bb85a16c10916f30/lib/python2.7/site-packages/pip/req.py", line 1105, in prepare_files
    dist = list(pkg_resources.find_distributions(location))[0]
IndexError: list index out of range
@alex
Copy link
Member Author

alex commented Aug 4, 2013

This is pip 1.4:

(bb85a16c10916f30)Alexanders-MacBook-Pro:bb85a16c10916f30 alex_gaynor$ pip --version
pip 1.4 from /Users/alex_gaynor/.virtualenvs/bb85a16c10916f30/lib/python2.7/site-packages (python 2.7)

@alex
Copy link
Member Author

alex commented Aug 4, 2013

And my pip.conf:

(bb85a16c10916f30)Alexanders-MacBook-Pro:bb85a16c10916f30 alex_gaynor$ cat ~/.pip/pip.conf
[global]
timeout = 15
download_cache = ~/.pip/cache
allow-all-external = false
no-allow-insecure = false
use-wheel = true
wheel-dir = /Users/alex_gaynor/.pip/wheels
find-links = /Users/alex_gaynor/.pip/wheels

@dstufft
Copy link
Member

dstufft commented Aug 4, 2013

Steps to reproduce:

$ pip wheel --wheel-dir ./wheelhouse colorama
$ pip install --use-wheel --find-links ./wheelhouse --download=. colorama

@qwcode
Copy link
Contributor

qwcode commented Aug 5, 2013

pip install --download is not written to work with wheels. working on a fix with tests...

@qwcode
Copy link
Contributor

qwcode commented Aug 6, 2013

there's 2 issues in the example @dstufft gives

  1. --download doesn't work for wheels (the reason for the exception)
  2. --download doesn't work correctly for local find-links in any case (which is an odd scenario, but it should either work or fail as invalid option combination)

I'm willing to fix 1) for the patch release (1.4.1), but 2) needs a fair amount of effort to fix correctly and fill in the gaps in unit testing. I'll log an issue for that.

@dstufft
Copy link
Member

dstufft commented Aug 6, 2013

  1. is probably getting exposed now because of people using find-links to expose a wheelhouse to pip install.

I think that's reasonable though.

@qwcode
Copy link
Contributor

qwcode commented Aug 6, 2013

I use local find-links a lot (and the test suite does too). And we already recommend something similar here: http://www.pip-installer.org/en/latest/cookbook.html#fast-local-installs

Combining --download and local --find-links is odd because you're saying you want to download files you already have.

I don't think wheelhouse will make it more likely for someone to try to do this.

@dstufft
Copy link
Member

dstufft commented Aug 6, 2013

Some folks are recommending people add --find-links=$WHEEL_DIR to the ~/.pip/pip.conf which means anyone who takes that advice will be using --find-links all the time in cases where they wouldn't have before.

@qwcode
Copy link
Contributor

qwcode commented Aug 6, 2013

that's fine and only a problem if they then try to --download a requirement that will be fulfilled from those local dirs, which should still be uncommon

@qwcode
Copy link
Contributor

qwcode commented Aug 6, 2013

closing. merged #1113

@qwcode qwcode closed this as completed Aug 6, 2013
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 6, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

3 participants