When I specify version requirement with upper and lower bound, it fails to satisfy if there is version which contains letters exists.
pip install 'Django>=1.8,<1.9' --upgrade
I expect it will install version 1.8.11 as it is current newest 1.8.x version. It works in my computer. However it installs 1.9rc1 in another machine (OpenShift), while 1.9rc1 is not in range [1.8, 1.9) IMHO.
How does pip version comparison works? How to specify version requirement [1.8, 1.9) correctly?
Thanks a lot
Related
I want to install a specific version of PyTorch (inside a Dockerfile) to handle modern GPUs: 1.8.1+cu111. Please note the local version identifier. I then install (both via pip) a library that requests torch>=1.8.1 as a dependency. For some reason, this uninstalls my 1.8.1+cu111 and replaces it with vanilla 1.10.0, despite the custom version with "local version specifier" should be taken as valid as PEP 0440 says (...local version labels MUST be ignored entirely when checking...) and it's what is happening normally, e.g. here or even for me when I try to re-install PyTorch by hand:
pip install "torch>=1.8.1"
Requirement already satisfied: torch>=1.8.1 in /usr/local/lib/python3.7/dist-packages (1.8.1+cu111)
But no, when I install my library, I get this:
...
Collecting torch>=1.8.1
Using cached torch-1.10.0-cp37-cp37m-manylinux1_x86_64.whl (881.9 MB)
...
Installing collected packages: torch,...
Attempting uninstall: torch
Found existing installation: torch 1.8.1+cu111
Uninstalling torch-1.8.1+cu111:
Successfully uninstalled torch-1.8.1+cu111
How can I make it keep the pre-installed 1.8.1+cu111?
In the PEP040, you have above:
When multiple candidate versions match a version specifier, the preferred version SHOULD be the latest version as determined by the consistent ordering defined by the standard Version scheme. Whether or not pre-releases are considered as candidate versions SHOULD be handled as described in Handling of pre-releases.
I think this because you are using an inclusive specifier where local version identifiers are NOT permitted
Can you specify the exact version with pip install "torch==1.8.1+cu111" ? Maybe only 1.8.1 works.
ERROR: Could not find a version that satisfies the requirement my-package==2021.4.* (from versions: 0.0.2, 2021.4.1.dev44+gd452819a91.d20210528, 2021.5.26)
This looks weird, right? Why doesn't the second one in the list match???
~=2021.4.1 doesn't work either. =~2021.4 installs 2021.5.26
The only way I found for it to work is to spell it out completely: ==2021.4.1.dev44+gd452819a91.d20210528
Why don't the match operators work?
By default, pip ignores pre-release and development versions. Per the pip documentation on pre-release versions:
Starting with v1.4, pip will only install stable versions as specified by pre-releases by default. If a version cannot be parsed as a compliant PEP 440 version then it is assumed to be a pre-release.
If a Requirement specifier includes a pre-release or development version (e.g. >=0.0.dev0) then pip will allow pre-release and development versions for that requirement. This does not include the != flag.
If you want pip to also match pre-release and development version against the version specifier, you can pass the --pre flag when invoking pip install:
I have a custom pypi server, that I am installing files from. I attempt to upgrade from version 0.0.1 to a newer version of my own custom module. It is not detecting the later version. When I do a pip install 'mymodule>=17' I see:
Could not find a version that satisfies the requirement mymodule>=17
(from versions: 17.0828.222133-e1e0fd9, 17.0828.222305-e1e0fd9,
17.830.210154-e1e0fd9, 0.0.1)
Notice the versions show up, but it will never detect the 17.X versions with the git sha on the end. Ideas? Why would this be?
Due to the hyphen, 17.0828.222133-e1e0fd9 and the like are not valid version specifiers as defined in PEP 440. As a result, they are treated as "legacy version" strings by pip's internals and are sorted less than all valid version strings. Hence, as far as pip is concerned, these versions are not greater than 17.
I am trying to install a specific version of django-cms, thus executing pip install django-cms==3.0.5. That gives me the error No matching distribution found for django-mptt==0.5.2,==0.6,==0.6.1 (from django-cms==3.0.5). And indeed, on github the setup.py file specifies the requirement django-mptt==0.5.2,==0.6,==0.6.1.
The specification says that the comma serves as a logical 'and' operator but obviously no version can be 0.5.2, 0.6 AND 0.6.1 at the same time and thus the requirement is not matched. Just installing one of those versions via pip install django-mptt==0.5.2 works without a problem but there is still the same error about django-cms==3.0.5.
Can anyone shed light on this?
This was a bug in django-cms version 3.0.5. You can see the issue here: https://github.com/divio/django-cms/issues/3704.
You can try installing version 3.0.16 if you need to stay on the 3.0 release. If you REALLY need version 3.0.5, you can install pip==1.5.6, and django-cms should still install properly.
Edit Starting from pip version 6.0, multiple == version specifiers for a single package no longer work. One of the developers commented on Github:
This is the new expected behavior from PEP 440.
The old behavior of setuptools was confusing and didn't do what most
people expected it to do. PEP 440 simplified it by changing the , to a
logical AND statement.
See https://github.com/pypa/pip/issues/2258.
My project Pyrr was previously using versions that were datestamps.
The last datestamped version was:
version='20130321'
I want to move to a proper major.minor.micro format.
I've updated a new package to PyPi in this format.
version='0.1.0'
When I pip install pyrr I still get the 20130321 version.
$ yolk -V pyrr
pyrr 0.1.0
$ pip install pyrr
Downloading/unpacking pyrr
Downloading pyrr-20130321.tar.gz
<snip>
PyPi has the over versions marked as hidden and the 0.1.0 as the only version not marked hidden.
What do I have to do to get pip / pypi to download the 0.1.0 version instead of the older datestamp versions?
20130321 is the major version, which is obviously higher than 0, therefor version 20130321 is considered the latest version.
The easiest way to fix this would be to delete the outdated version using the webinterface.
If the older versions should still exist, you could download them and reupload them using a newer version. e.g. 0.0.20130321.
If people depend on your package without a version, they wouldn't notice the new versioning system.
If people do depend on a specific version, they would have to change their version dependency. This could be considered annoying, but it is inevitable and it's a small change for them.