Jaki jest cel „pip install - user…”?

Od pip install --help:

 --user      Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%\Python on
             Windows. (See the Python documentation for site.USER_BASE for full details.)

Dokumentacja dla site.USER_BASE to przerażający tunel czasoprzestrzenny o interesującym * temacie NIX, którego nie rozumiem.

Do czego służy --userzwykły angielski? Dlaczego intallowanie pakietu ma ~/.local/znaczenie? Dlaczego po prostu nie umieścić pliku wykonywalnego gdzieś w mojej $ PATH?

pip domyślnie instaluje pakiety Pythona w katalogu systemowym (np. /usr/local/lib/python3.4). Wymaga to dostępu do konta root.

--user sprawia, że ​​pip instaluje pakiety w twoim katalogu domowym, co nie wymaga żadnych specjalnych uprawnień.

--user instaluje się w site.USER_SITE .

W moim przypadku tak było /Users/.../Library/Python/2.7/bin. Dodałem to do mojej ŚCIEŻKI (w ~/.bash_profilepliku):

export PATH=$PATH:/Users/.../Library/Python/2.7/bin

Inne odpowiedzi wspominają, site.USER_SITEgdzie umieszczane są pakiety Pythona. Jeśli szukasz plików binarnych, wejdą one{site.USER_BASE}/bin .

Jeśli chcesz dodać ten katalog do ścieżki wyszukiwania powłoki, użyj:

export PATH="${PATH}:$(python3 -c 'import site; print(site.USER_BASE)')/bin"

Tylko ostrzeżenie:

Zgodnie z tym problemem , --userobecnie nie jest ważny w wirtualnej envpip , ponieważ lokalizacja użytkownika nie ma sensu w środowisku wirtualnym.

Więc nie używaj pip install --user some_pkg w środowisku wirtualnym , w przeciwnym razie środowiska wirtualne pipbędą mylone. Zobacz tę odpowiedź, aby uzyskać więcej informacji.

Najlepszym sposobem jest instalacja virtualenvi nie wymaga--user zamieszania. Zyskasz większą elastyczność i nie będziesz się martwić o blokowanie różnych wersji i projektów Pythona za każdym razem, gdy instalujesz pakiet.

https://virtualenv.pypa.io/en/stable/

W systemie macOS powodem użycia --userflagi jest upewnienie się, że nie uszkodzimy bibliotek, na których opiera się system operacyjny. Konserwatywne podejście do wielu użytkowników MacOS jest unikanie instalowania lub aktualizowania PIP z poleceniem, które wymagają sudo. Dlatego obejmuje to instalację do/usr/local/bin ...

Ref: Instalowanie Pythona dla Neovim ( https://github.com/zchee/deoplete-jedi/wiki/Setting-up-Python-for-Neovim )

Nie mam wszystko jasne, dlaczego zainstalowanie na /usr/local/binryzyko na Mac biorąc pod uwagę fakt, że system opiera się tylko na plikach binarnych Python w /Library/Frameworks/i /usr/bin. Podejrzewam, że dzieje się tak, ponieważ, jak wspomniano powyżej, instalacja w /usr/local/binwymaga, sudoco otwiera drogę do popełnienia kosztownego błędu w bibliotekach systemowych. Dlatego zainstalowanie w ~/.local/binto pewny sposób ognia, aby uniknąć tego ryzyka.

Ref: Używanie Pythona na komputerze Mac ( https://docs.python.org/2/using/mac.html )

Wreszcie, o ile korzyści płynące z instalowania pakietów w /usr/local/bin, zastanawiam się, czy sensowne jest zmienić właściciela katalogu z rootna user? Pozwoliłoby to uniknąć konieczności używania, sudojednocześnie chroniąc przed wprowadzaniem zmian zależnych od systemu. * Czy to domyślne ustawienie bezpieczeństwa jest reliktem tego, jak systemy Unix były częściej używane w przeszłości (jako serwery)? A przynajmniej dobra droga dla użytkowników komputerów Mac, którzy nie hostują serwera?

* Uwaga: Wydaje się, że funkcja ochrony integralności systemu (SIP) komputera Mac chroni użytkownika przed zmianą bibliotek zależnych od systemu.

- E

Bez środowisk wirtualnych

pip <command> --user zmienia zakres bieżącej komendy pip, tak aby działała na lokalnej lokalizacji instalacji lokalnego konta python użytkownika, a nie na lokalizacji instalacji całego systemu, która jest domyślna.

• Zobacz Instalacje użytkownika w Podręczniku użytkownika PIP.

To naprawdę ma znaczenie tylko na komputerze z wieloma użytkownikami. Wszystko, co zostanie zainstalowane w lokalizacji systemu, będzie widoczne dla wszystkich użytkowników, więc instalacja w lokalizacji użytkownika sprawi, że instalacja pakietu będzie oddzielona od innych użytkowników (nie będą go widzieć i będą musieli zainstalować go osobno, aby z niego korzystać). Ponieważ mogą występować konflikty wersji, instalacja pakietu z zależnościami wymaganymi przez inne pakiety może powodować problemy, dlatego najlepiej nie wypychać wszystkich pakietów, których dany użytkownik używa do lokalizacji instalacji systemu.

• Jeśli jest to maszyna dla jednego użytkownika, instalacja na nim jest niewielka lub żadna --user lokalizacji . Zostanie zainstalowany w innym folderze, który może, ale nie musi, zostać dodany do ścieżki, w zależności od pakietu i sposobu jego użycia (wiele pakietów instaluje narzędzia wiersza polecenia, które muszą znajdować się na ścieżce, aby uruchomić się z powłoki) .
• Jeśli jest to komputer z wieloma użytkownikami, --userpreferowane jest używanie roota / sudo lub wymaganie instalacji administratora i wpływanie na środowisko Python każdego użytkownika, z wyjątkiem przypadków ogólnych pakietów, które administrator chce domyślnie udostępnić wszystkim użytkownikom.
  • Uwaga: W komentarzach w większości instalacji Unix / Linux wskazano, że instalacje systemowe powinny używać ogólnego menedżera pakietów, takiego jak apt, zamiast pip.

Z wirtualnymi środowiskami

• Dowiedz się więcej o instalowaniu pakietów ze środowiskami wirtualnymi w dokumentacji Pakietu Python .
• Przeczytaj o tym, jak tworzyć i używać środowisk wirtualnych oraz o venvpoleceniu w dokumentacji Python VENV .

--userOpcja w aktywnym środowisku venv / virtualenv zainstaluje do lokalnej lokalizacji python użytkownik (taki sam jak bez środowisku wirtualnym).

Pakiety są domyślnie instalowane w środowisku wirtualnym, ale jeśli --usergo użyjesz , wymusi to instalację poza środowiskami wirtualnymi, w katalogu skryptów użytkowników Pythona (w systemie Windows jest to obecnie c:\users\<username>\appdata\roaming\python\python37\scriptsdla mnie w Pythonie 3.7).

Jednak nie będzie można uzyskać dostępu do instalacji systemu lub użytkownika z poziomu środowiska wirtualnego (nawet jeśli był używany --userw środowisku wirtualnym).

Jeśli zainstalujesz środowisko wirtualne z --system-site-packagesargumentem, będziesz miał dostęp do folderu skryptów systemowych dla Pythona. Wydaje mi się, że dotyczy to również folderu skryptu python użytkownika, ale nie jestem pewien. Może to jednak mieć niezamierzone konsekwencje i nie jest to zamierzony sposób korzystania ze środowisk wirtualnych.

Lokalizacja systemu Python i folderów instalacji lokalnych użytkowników

Możesz znaleźć lokalizację folderu instalacyjnego użytkownika dla Pythona za pomocą python -m site --user-base. Znajduję sprzeczne informacje w pytaniach i odpowiedziach, dokumentacji i faktycznie używam tego polecenia na komputerze, aby określić, jakie są ustawienia domyślne, ale znajdują się one w katalogu osobistym użytkownika ( ~skrót w * nix i c:\users\<username>zazwyczaj w systemie Windows).

Inne szczegóły

--userOpcja nie jest ważna dla każdego polecenia. Na przykład pip uninstallznajdzie i odinstaluje pakiety, gdziekolwiek zostały zainstalowane (w folderze użytkownika, folderze środowiska wirtualnego itp.), A --useropcja jest nieprawidłowa.

Rzeczy zainstalowane z pip install --user zostaną zainstalowane w lokalizacji lokalnej, która będzie widoczna tylko dla bieżącego konta użytkownika i nie będzie wymagała dostępu do konta root (w * nix) ani dostępu administratora (w systemie Windows).

W --usermodyfikuje opcja wszystkie pip polecenia, które akceptują go zobaczyć / działające na użytkownika zainstalować folderu, więc jeśli używasz pip list --userto tylko pokazać Pakiety zainstalowane pip install --user.

Dlaczego nie po prostu umieścić gdzieś plik wykonywalny w mojej $ PATH

~/.local/bin directoryteoretycznie oczekuje się, że będzie w twoim $PATH.

Według tych osób jest to błąd, który nie dodaje go w $PATHtrakcie używania systemd.

Ta odpowiedź wyjaśnia ją szerzej.

Ale nawet jeśli twoja dystrybucja zawiera ten ~/.local/binkatalog do$PATH , być może w postaci następującej (wewnątrz ~/.profile):

if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

co wymagałoby wylogowania i ponownego zalogowania , jeśli katalogu nie było wcześniej.