2012-03-31 3 views
11

Gist: Qual è il modo migliore per rilevare in setup.py che siamo stati attivati ​​da pip install package?rileva pip in setup.py

Sfondo: Ho un pacchetto (associazioni per una libreria C), per il quale fornisco uova che includono la libreria stessa. Nel mio readme/doc ho notato che questo pacchetto è 'easy_install-able' su alcune piattaforme. Quando si costruisce dalla fonte (ad esempio con pip), la libreria stessa è una dipendenza di build. Il problema è che in qualche modo ho regolarmente utenti confusi che credono erroneamente che pip sia un sostituto completo per easy_install, e aspettiamo che pip install package funzioni su sistemi senza la libreria, o anche senza un compilatore, dove l'uovo è ciò che realmente vogliono.

Vorrei rilevare che la generazione è stata attivata da pip, quindi posso fornire un messaggio amichevole "pip! = Easy_install" se non riesce a causa della mancanza della libreria. Non ha bisogno di essere perfetto, basta prendere i casi più comuni di pip install package. A un esame, non sembra che ci sia un modo particolarmente robusto per fare questo, e il migliore che abbia venire in mente è:

probably_using_pip = '--single-version-externally-managed' in sys.argv 

Esiste un modo migliore (o, meglio ancora, ufficiale) per rilevare pip da setup.py?

+0

Perché il messaggio di errore deve essere diverso da quando si esegue "setup.py install" quando la libreria non è presente? – joeforker

+0

Quando si esegue 'setup.py install', si sta certamente costruendo dal sorgente. Quando esegui 'pip install' le persone potrebbero aspettarsi i binari ma non riceverli (gli utenti non capiscono le differenze tra pip e easy_install). Questa domanda non è più rilevante per il mio caso particolare, perché pip 1.5 supporta le ruote di default. – minrk

+0

Un altro contesto: al momento della richiesta (due anni fa), il mio pacchetto veniva spesso installato su macchine prive di compilatore e pip non supportava formati binari. easy_install ha funzionato bene, ma pip non sarebbe riuscito a compilare. Per questo motivo, volevo informare le persone la cui installazione di "pipe" non è riuscita e che easy_install potrebbe essere preferibile. – minrk

risposta

-1

Potresti provare a utilizzare il sottoprocesso/os per provare a eseguire pip, quindi se non riesce, sai che non c'è pip.

+0

Ma se non lo fa, non significherà nulla. –

+3

Sapere che il pip esiste non aiuta, perché sto cercando se sia effettivamente in uso. Inoltre, un controllo più semplice della presenza di pip sarebbe "import pip". – minrk

3

__file__ in installazione fornisce qualcosa come /tmp/pip-DNpsLw-build/setup.py se eseguito da pip.

from setuptools import setup 

def determineInstaller(): 
    if 'pip' in __file__: 
     print('========pip triggered build========') #add smiley for friendliness :) 
    return 'dummy description' 

setup(name='bla', 
     version='0.0', 
     description=determineInstaller(), 
    ) 
+1

Questa è un'altra buona nota, anche se vorrei essere più specifico per ridurre i falsi positivi, ad es .: 'using_pip = os.path.basename (os.path.dirname (__ file __)). Startswith ('pip -')'. Dato che nessuno sta fornendo una risposta documentata o ufficiale e non vulnerabile a falsi positivi e/o cambiamenti nelle API private, sembrerebbe che gli autori di pip non intendano che i pacchetti siano in grado di dire che il pip è in uso. – minrk

+0

+1 per gentilezza – Cacovsky

+1

La soluzione '__file__' non sembra funzionare con Py 2.7 2014-10-27, nessun 'pip' in' __file__'. 'os.environ' ha una chiave '_' con valore '/ run/shm/r/ven/bin/pip'. Questo è l'installazione tramite 'pip install -e. -U', quindi forse la soluzione '__file__' funziona con le installazioni di pip più tipiche, ma forse la chiave' _' è più generale? –

0

Avete considerato di costruire wheels che pip può installare?

+0

Costruisco ruote ora. Quando ho posto questa domanda, le ruote non esistevano. – minrk