CODEWITHSUNDEEP
pythongitpip
dukebody
dukebody

Reputation: 7185

pip unexpectedly not installing latest version of git package with branch/commit pinning

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?

Upvotes: 14

Views: 5164

Answers (3)

schaller.david
schaller.david

Reputation: 31

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.

Upvotes: 3

therealak12
therealak12

Reputation: 1316

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.

Upvotes: 3

Ryne Everett
Ryne Everett

Reputation: 6819

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.

Upvotes: 14

Related Questions