Pourquoi pip installe-t-il une ancienne version de mon paquet?
Je viens de télécharger une nouvelle version de mon paquet sur PyPi (1.2.1.0-r4): Je peux télécharger le fichier Egg et l'installer avec easy_install. La version est extraite correctement. Mais lorsque j'essaye d'installer avec pip, il installe plutôt la version 1.1.0.0. Même si je spécifie explicitement la version à utiliser avec pip install -Iv tome==1.2.1.0-r4, je reçois le message suivant: Requested tome==1.2.1.0-r4, but installing version 1.1.0.0, mais je ne comprends pas pourquoi.
J'ai vérifié deux fois avec parse_version et confirmé que la chaîne de version sous 1.2.1 était supérieure à celle sous 1.1.0, comme indiqué:
>>> from pkg_resources import parse_version as pv
>>> pv('1.1.0.0') < pv('1.2.1.0-r4')
True
>>>
Vous avez donc une idée de pourquoi choisir d'installer plutôt la version 1.1.0?
Ceci est une excellente question. Il m'a fallu une éternité pour comprendre. C'est la solution qui fonctionne pour moi:
Apparemment, si pip peut trouver une version locale du paquet, pip préfèrera les versions locales aux versions distantes. J'ai même déconnecté mon ordinateur d'Internet et essayé à nouveau - lorsque pip a toujours installé le package avec succès et ne s'est même pas plaint, la source était évidemment locale.
La partie vraiment déroutante, dans mon cas, est que pip a trouvé les versions les plus récentes sur pypi , les a signalées, puis est allé de l’avant et a réinstallé l’ancienne version de toute façon ... arggh. En outre, il ne m'a pas dit ce qu'il faisait et pourquoi.
Alors, comment ai-je résolu ce problème?
Vous pouvez obtenir que pip donne une sortie détaillée en utilisant l'indicateur -v ... mais un seul ne suffit pas. Je RTFM-ed l'aide, qui dit que vous pouvez faire -v plusieurs fois, jusqu'à 3x, pour une sortie plus détaillée. Alors j'ai fait:
pip install -v -v -v <my_package>
Puis j'ai regardé à travers la sortie. Une ligne a attiré mon attention:
La source dans/tmp/pip-build-root/a la version 0.0.11, qui répond à l'exigence <my_package>
J'ai supprimé ce répertoire, après quoi pip a installé la dernière version de pypi.
Merci à Marcus Smith , qui fait un travail incroyable en tant que mainteneur de pip, ceci a été corrigé dans la version 1.4 de pip qui a été publiée le 2013-07-23.
Informations pertinentes provenant de changelog pour cette version
Correction d'un certain nombre de problèmes (n ° 413, n ° 709, n ° 634, n ° 602 et n ° 939) liés à nettoyer et ne pas réutiliser les répertoires de construction. (Pull # 865, # 948)
Essayez de télécharger à nouveau le paquet avec:
pip install --no-cache-dir --upgrade <package>
J'ai trouvé ici qu'il existe un bogue connu dans pip qui ne vérifie pas la version s'il existe un répertoire de construction avec des sources non compressées. J'ai vérifié cela sur mon paquet troublant et après avoir supprimé ses sources du répertoire de construction, pip a installé la version requise.
Si vous utilisez une version pip fournie avec certains packages de distribution (par exemple, Ubuntu python-pip), vous devrez peut-être installer une version plus récente de pip:
Mettez à jour pip à la dernière version:
Sudo pip install -U pip
En cas de "virtualenv", passez "Sudo":
pip install -U pip
La commande suivante peut être requise, si votre shell rapporte quelque chose comme -bash: /usr/bin/pip: No such file or directory après la mise à jour de pip:
hash -d pip
Maintenant, installez votre paquet comme d'habitude:
pip install -U foo
ou
pip install foo==package.version.here
Vous avez le même problème pour mettre à jour le pika 0.9.5 à 0.9.8. Le seul moyen de travailler consistait à installer depuis tarball: pip install https://pypi.python.org/packages/source/p/pika/pika-0.9.8.tar.gz.
J'ai trouvé que si vous utilisez des microversions, pip ne semble pas les reconnaître. Par exemple, nous n'avons pas pu obtenir la version 1.9.9.1 à mettre à niveau.
Dans mon cas, j'ai dû supprimer le dossier .pip de mon répertoire personnel, puis j'ai pu obtenir des versions ultérieures de plusieurs bibliothèques. Notez que c'était sur linux.
pip --version
pip 18.1 from /usr/lib/python2.7/site-packages/pip (python 2.7)
virtualenv --version
15.1.0
Dans mon cas, la version de Python utilisée (3.4) ne répondait pas aux exigences des dépendances de Django 2.1 (python> = 3.5).