Dlaczego pip instaluje starą wersję mojego pakietu?

Właśnie przesłałem nową wersję mojego pakietu do PyPi (1.2.1.0-r4): mogę pobrać plik egg i zainstalować go za pomocą easy_install, a wersja sprawdza się poprawnie. Ale kiedy próbuję zainstalować za pomocą pip, zamiast tego instaluje wersję 1.1.0.0. Nawet jeśli wyraźnie określę wersję do pipowania pip install -Iv tome==1.2.1.0-r4, otrzymuję ten komunikat :, Requested tome==1.2.1.0-r4, but installing version 1.1.0.0ale nie rozumiem dlaczego.

Dwukrotnie sprawdziłem parse_versioni potwierdziłem, że ciąg wersji w 1.2.1 jest większy niż w 1.1.0, jak pokazano:

>>> from pkg_resources import parse_version as pv
>>> pv('1.1.0.0') < pv('1.2.1.0-r4')
True
>>>

Więc jakikolwiek pomysł, dlaczego zamiast tego zdecydował się zainstalować 1.1.0?

To doskonałe pytanie. Wieki zajęło mi to rozgryzienie. To rozwiązanie, które działa u mnie:

Najwyraźniej, jeśli pipmożna znaleźć lokalną wersję pakietu, pipwolałby wersje lokalne od zdalnych. Odłączyłem nawet komputer od Internetu i spróbowałem ponownie - gdy pippakiet nadal został pomyślnie zainstalowany i nawet nie narzekałem, źródło było oczywiście lokalne.

W moim przypadku naprawdę zagmatwana część polegała na tym, że pipznalazłem nowsze wersje na pypi , zgłosiłem je, a następnie i tak zainstalowałem ponownie starszą wersję ... arggh. Nie powiedział mi też, co robi i dlaczego.

Jak więc rozwiązałem ten problem?

Możesz uzyskać pipszczegółowe dane wyjściowe za pomocą -vflagi ... ale jedno nie wystarczy. Opublikowałem pomoc w formacie RTFM, który mówi, że możesz wykonać -vwiele razy, do 3 razy, aby uzyskać bardziej szczegółowe wyniki. Więc zrobiłem:

pip install -vvv <my_package>

Następnie przejrzałem dane wyjściowe. Jedna linijka zwróciła moją uwagę:

Źródło w / tmp / pip-build-root / ma wersję 0.0.11, która spełnia wymaganie <my_package>

Usunąłem ten katalog, po czym pipzainstalowałem najnowszą wersję z pypi.

Spróbuj wymusić ponowne pobranie pakietu za pomocą:

pip install --no-cache-dir --upgrade <package>

Dzięki Marcusowi Smithowi , który wykonuje niesamowitą pracę jako konserwator pip, zostało to naprawione w wersji 1.4 pip, która została wydana 23-07-23.

Istotne informacje z dziennika zmian dla tej wersji

Naprawiono szereg problemów (# 413, # 709, # 634, # 602 i # 939) związanych z czyszczeniem i brakiem ponownego wykorzystania katalogów kompilacji. (Pociągnij # 865, # 948)

Odkryłem tutaj , że w pip jest znany błąd polegający na tym, że nie sprawdza wersji, jeśli istnieje katalog kompilacji z rozpakowanymi źródłami. Sprawdziłem to na moim kłopotliwym pakiecie i po usunięciu jego źródeł z katalogu kompilacji, pip zainstalował wymaganą wersję.

Jeśli używasz pipwersji, która jest dostarczana z niektórymi pakietami dystrybucyjnymi (np. Ubuntu python-pip), może być konieczne zainstalowanie nowszej pipwersji:

Zaktualizuj pipdo najnowszej wersji:

sudo pip install -U pip

W przypadku „virtualenv” pomiń „sudo”:

pip install -U pip

Następujące polecenie może być wymagane, jeśli twoja powłoka zgłasza coś takiego -bash: /usr/bin/pip: No such file or directorypo pipaktualizacji:

hash -d pip

Teraz zainstaluj pakiet jak zwykle:

pip install -U foo

lub

pip install foo==package.version.here

Ten sam problem dotyczy aktualizacji pika z 0.9.5 do 0.9.8. Sposób, w jaki działa tylko było zainstalować z archiwum: pip install https://pypi.python.org/packages/source/p/pika/pika-0.9.8.tar.gz.

W moim przypadku musiałem usunąć .pipfolder w moim katalogu domowym, a następnie mogłem uzyskać późniejsze wersje wielu bibliotek. Zauważ, że było to w systemie Linux.

pip --version
pip 18.1 from /usr/lib/python2.7/site-packages/pip (python 2.7)
virtualenv --version
15.1.0

Zauważyłem, że jeśli używasz mikroprzerzutów, pip wydaje się ich nie rozpoznawać. Na przykład nie mogliśmy pobrać wersji 1.9.9.1 do aktualizacji.

W moim przypadku używana wersja Pythona (3.4) nie spełniała wymagań dotyczących zależności Django 2.1 (python> = 3.5).

W moim przypadku instaluję za pomocą pipa pakiet .tar.gz z Artifactory, do którego robię wiele aktualizacji. Aby nadpisać moje buforowane pliki Pythona i zawsze pobrać / zainstalować najnowsze, które udało mi się uruchomić:

pip install --no-cache-dir --force-reinstall <path/to/tar.gz>

Powinieneś zobaczyć to ponownie, pobierz wszystkie niezbędne pliki i zainstaluj je, zamiast korzystać z lokalnej pamięci podręcznej.

W moim przypadku ktoś opublikował najnowszą wersję pakietu z pythonem2, więc próbując pip3 installgo pobrać, złapał starszą wersję, która została zbudowana za pomocą python3.

Przydatne rzeczy do sprawdzenia podczas debugowania:

• Jeśli pip installtwierdzi, że nie może znaleźć wersji, sprawdź, czy pip searchją widzi.
• Spójrz na sekcję „Download Files” w repozytorium pypi - nazwy plików mogą sugerować, co jest nie tak (w moim przypadku widziałem -py2-to jasno jak w dzień).
• Jak sugerują inni, spróbuj uruchomić pip install --no-cache-dirna wypadek, gdyby pip nie zawracał sobie głowy pytaniem o Internet, ponieważ ma już lokalną odpowiedź.

Ukryłem niewersjonowane pliki na karcie Git w PyCharm, które były instalowane, pip install .mimo że nie widziałem ich nigdzie indziej.

Znalezienie go dla mnie zajęło dużo czasu, opublikowanie tego w nadziei, że pomoże to komuś innemu.

Na wszelki wypadek, gdyby ktoś inny miał kłopoty z aktualizacją torchtext (lub prawdopodobnie jakąkolwiek inną torchbiblioteką):

Chociaż https://pypi.org/project/torchtext/ stwierdza, że ​​można uruchomić pip install torchtext, musiałem zainstalować go podobnie jak torchpodając --find-linksaka -f:

pip install torchtext===0.8.1 -f https://download.pytorch.org/whl/torch_stable.html

Irytowało mnie to, że PyCharm wskazał mi nową wersję, ale nie mogłem jej znaleźć podczas próby aktualizacji do niej. Wydaje mi się, że PyCharm wykorzystuje swój własny mechanizm do wykrywania nowych wersji. Następnie, wywołując pippod maską, nie znalazł nowej wersji bez --find-linksopcji.