Qual è lo scopo di "pip install --user ..."?

Da 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.)

La documentazione per site.USER_BASE è un terrificante wormhole di argomenti interessanti * NIX che non capisco.

Qual è lo scopo di --userin inglese semplice? Perché è importante installare il pacchetto ~/.local/? Perché non mettere semplicemente un eseguibile da qualche parte nel mio $ PATH?

pip per impostazione predefinita installa i pacchetti Python in una directory di sistema (come /usr/local/lib/python3.4). Ciò richiede l'accesso come root.

--user crea invece pacchetti di installazione pip nella directory home, che non richiede alcun privilegio speciale.

--userinstalla in site.USER_SITE.

Per il mio caso, lo era /Users/.../Library/Python/2.7/bin. Quindi l'ho aggiunto al mio PERCORSO (nel ~/.bash_profilefile):

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

Altre risposte menzionano site.USER_SITEcome dove vengono posizionati i pacchetti Python. Se stai cercando binari, questi vanno dentro{site.USER_BASE}/bin .

Se si desidera aggiungere questa directory al percorso di ricerca della shell, utilizzare:

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

Solo un avvertimento:

Secondo questo problema , --userattualmente non è valido all'interno di un env virtualepip , poiché la posizione di un utente non ha davvero senso per un ambiente virtuale.

Quindi non utilizzare pip install --user some_pkg all'interno di un ambiente virtuale , altrimenti l'ambiente virtuale pipverrà confuso. Vedi questa risposta per maggiori dettagli.

Il modo migliore per installare è virtualenve non richiede il--user confusione. Otterrai una maggiore flessibilità e non preoccuparti di ostruire le diverse versioni e progetti di Python ogni volta che installi un pacchetto.

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

Su macOS, la ragione per usare il --userflag è assicurarsi che non corrompiamo le librerie su cui si basa il sistema operativo. Un approccio conservativo per molti utenti macOS è quello di evitare l'installazione o l'aggiornamento di pip con un comando che richiede sudo. Pertanto, ciò include l'installazione su/usr/local/bin ...

Rif: Installazione di python per Neovim ( https://github.com/zchee/deoplete-jedi/wiki/Setting-up-Python-for-Neovim )

Non sono del tutto chiaro il motivo per cui l'installazione in /usr/local/binè un rischio su un Mac dato il fatto che il sistema si basa solo su binari Python in /Library/Frameworks/e /usr/bin. Ho il sospetto che sia perché, come notato sopra, l'installazione in /usr/local/binrichiede di sudoaprire la porta a fare un errore costoso con le librerie di sistema. Pertanto, l'installazione in ~/.local/binè un modo sicuro per evitare questo rischio.

Rif: usare python su un Mac ( https://docs.python.org/2/using/mac.html )

Infine, nella misura in cui c'è un vantaggio nell'installare pacchetti in /usr/local/bin, mi chiedo se abbia senso cambiare il proprietario della directory da roota user? Ciò eviterebbe di doverlo utilizzare sudopur proteggendo da eventuali modifiche dipendenti dal sistema. * Si tratta di un'impostazione predefinita di sicurezza una reliquia di come i sistemi Unix venivano usati più spesso in passato (come server)? O almeno, un buon modo per gli utenti Mac che non ospitano un server?

* Nota: anche la funzionalità SIP (System Integrity Protection) di Mac sembra proteggere l'utente dal modificare le librerie dipendenti dal sistema.

- E

Senza ambienti virtuali

pip <command> --user modifica l'ambito del comando pip corrente in modo che funzioni sulla posizione di installazione del pacchetto python locale dell'account utente corrente, anziché sulla posizione di installazione del pacchetto a livello di sistema, che è l'impostazione predefinita.

• Vedere Installazioni utente nella Guida dell'utente PIP.

Questo conta davvero solo su una macchina multiutente. Qualsiasi cosa installata nella posizione del sistema sarà visibile a tutti gli utenti, quindi l'installazione nella posizione dell'utente manterrà l'installazione del pacchetto separata dagli altri utenti (non la vedranno e dovranno installarla separatamente per usarla). Poiché possono esserci conflitti di versione, l'installazione di un pacchetto con dipendenze richieste da altri pacchetti può causare problemi, quindi è meglio non inviare tutti i pacchetti che un determinato utente utilizza nel percorso di installazione del sistema.

• Se si tratta di una macchina per utente singolo, l'installazione non può essere diversa o inesistente --user. Verrà installato in una cartella diversa, che potrebbe essere necessario o meno aggiungere al percorso, in base al pacchetto e al modo in cui viene utilizzato (molti pacchetti installano strumenti da riga di comando che devono trovarsi sul percorso per essere eseguiti da una shell) .
• Se si tratta di una macchina multiutente, --usersi preferisce utilizzare root / sudo o richiedere l'installazione dell'amministratore e influire sull'ambiente Python di ogni utente, tranne nei casi di pacchetti generali che l'amministratore desidera rendere disponibili a tutti gli utenti per impostazione predefinita.
  • Nota: per commenti, sulla maggior parte delle installazioni Unix / Linux è stato sottolineato che le installazioni di sistema dovrebbero usare il gestore pacchetti generale, come apt, anziché pip.

Con ambienti virtuali

• Scopri di più sull'installazione di pacchetti con ambienti virtuali nella documentazione di Python Packaging .
• Leggi come creare e usare ambienti virtuali e il venvcomando nei documenti VENV di Python .

L' --useropzione in un ambiente venv / virtualenv attivo verrà installata nella posizione python dell'utente locale (come se non fosse presente un ambiente virtuale).

I pacchetti sono installati nell'ambiente virtuale per impostazione predefinita, ma se lo usi --userlo costringerà a installarsi al di fuori degli ambienti virtuali, nella directory degli script python degli utenti (in Windows, questo è attualmente c:\users\<username>\appdata\roaming\python\python37\scriptsper me con Python 3.7).

Tuttavia, non sarai in grado di accedere a un sistema o a un'installazione utente dall'interno di un ambiente virtuale (anche se lo hai utilizzato --userin un ambiente virtuale).

Se installi un ambiente virtuale con l' --system-site-packagesargomento, avrai accesso alla cartella degli script di sistema per Python. Credo che questo includesse anche la cartella degli script utente Python, ma non sono sicuro. Tuttavia, potrebbero esserci conseguenze indesiderate per questo e non è il modo previsto di utilizzare ambienti virtuali.

Posizione del sistema Python e delle cartelle di installazione dell'utente locale

Puoi trovare la posizione della cartella di installazione dell'utente per Python con python -m site --user-base. Sto trovando informazioni contrastanti nelle domande e risposte, nella documentazione e in realtà sto usando questo comando sul mio PC per sapere quali sono le impostazioni predefinite, ma si trovano sotto la home directory dell'utente ( ~collegamento in * nix e in c:\users\<username>genere per Windows).

Altri dettagli

L' --useropzione non è valida per ogni comando. Ad esempio pip uninstall, troveranno e disinstalleranno i pacchetti ovunque siano stati installati (nella cartella dell'utente, nella cartella dell'ambiente virtuale, ecc.) E l' --useropzione non è valida.

Le cose installate con pip install --userverranno installate in una posizione locale che verrà visualizzata solo dall'account utente corrente e non richiederà l'accesso root (su * nix) o l'accesso dell'amministratore (su Windows).

L' --useropzione modifica tutti i pip comandi che lo accettano per vedere / operare sulla cartella di installazione dell'utente, quindi se lo usi pip list --userti mostrerà solo i pacchetti installati pip install --user.

Perché non mettere semplicemente un eseguibile da qualche parte nel mio $ PATH

~/.local/bin directoryteoricamente dovrebbe essere nel tuo $PATH.

Secondo queste persone è un bug che non viene aggiunto durante l' $PATHutilizzo systemd.

Questa risposta lo spiega più ampiamente.

Ma anche se la tua distribuzione include la ~/.local/bindirectory in$PATH , potrebbe essere nella seguente forma (all'interno ~/.profile):

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

che richiederebbe di disconnettersi e accedere nuovamente , se la directory non era presente prima.