14

I have a requirements.txt file with the following line (among others):

git+https://github.com/lead-ratings/sexmachine.git@master#egg=SexMachine

When I do

pip install -r requirements.txt

I see

Requirement already satisfied (use --upgrade to upgrade): SexMachine from git+https://github.com/lead-ratings/sexmachine.git@master#egg=SexMachine in /home/myuser/virtual_env/lib/python2.7/site-packages (from -r requirements.txt (line 38))

And the package is not updated to the master version. Actually, it keeps some former version from PyPI I had listed in requirements.txt before.

It doesn't work either if I specify a commit in the pinning or use the --no-cache-dir flag. I'm using pip 6.1.1.

If I use the --upgrade flag then it works. But then what is the point of the pinning? Why does it say "Requirement already satisfied" if it really isn't?

dukebody
  • 7,025
  • 3
  • 36
  • 61

3 Answers3

14

Pip decides whether a requirement is met solely based on the version number (in setup.py). In your case the pypi version you installed previously had the same version number as the master branch of sexmachine, so pip did nothing.

It seems that the way to handle this is to always pass the -U / --upgrade flag:

pip install -r requirements.txt -U

The maintainer's position is given in #2835:

The behavior of pip here is correct then, we don't determine the version number of the project/file, that comes from inside the package. If they want to support arbitrary tags being independently identifiable they should have their setup.py adjust itself based on that.

Ryne Everett
  • 6,427
  • 3
  • 37
  • 49
  • 9
    But then what's the point of the branch/commit part in requirements.txt? One would think that pip is using the specified revision. This is really confusing. I opened https://github.com/pypa/pip/issues/2837 about this. – dukebody Jun 01 '15 at 17:58
  • Pip clones the branch/commit and then looks at the version number specified in it's setup.py. I agree that the behavior is confusing, but after thinking about it a while I'm inclined to agree with the maintainer. There's really no harm in specifying `-U` if that's the behavior you want, and it would be kind of weird if vcs requirements had the same behavior (always updated) regardless of whether the `-U` flag was passed. – Ryne Everett Jun 01 '15 at 18:38
  • But if I have installed, let's say, `scikit-learn==0.15` and then change the requirements.txt to `scikit-learn==0.16.1` and run `pip install -r requirements.txt`, the new version is downloaded and installed. The confusion comes from considering the `@rev` a pinning when it is not. I think this should be documented because it can lead to many errors. – dukebody Jun 01 '15 at 18:47
  • Agreed. I've used this feature for a long time without a hitch until running into an issue that forced me to read the source code and find out that I'd misunderstood how it worked all along. – Ryne Everett Jun 01 '15 at 19:03
3

In my case even -U or --upgrade didn't work. Pip also requires the version in the setup.py to differ in order to install the new version. By updating the package version in setup.py it worked.

therealak12
  • 1,178
  • 2
  • 12
  • 26
2

I had a similar problem when I created a conda environment with a pip installation for a package on GitHub pinned to a specific commit. Then I wanted to update this package with pip pinning it to another commit. The -U flag did not help. However, the --force-reinstall tag did.

schaller.david
  • 21
  • 2