virtualenv rilocabile - funziona davvero

Question

Ho continuato a cercare la risposta ma non ne ho trovata una. Ho una directory env virtuale, una dir di progetto con un req.txt. Quando eseguo pip -r req.txt, installa alcune app da github (sorgente) e altre da pypi. Quelli di pypi vanno bene dopo la chiamata rimotabile sul evn virtuale, tuttavia i collegamenti nei pacchetti del sito per le app che ha installato da github puntano ancora al vecchio percorso della directory.

Qualcun altro ha visto questo comportamento? Qualche modo veloce intorno ad esso? Inoltre, rilocabile non sta rispettando il flag --no-site-packages che era stato utilizzato originariamente su virtualenv. Una volta spostato il virtuale e riattivato, tutto è visibile dai pacchetti del sito del sistema. Documenti indica questo comportamento come un fatto, quindi mi chiedo se c'è un modo rapido per aggirare questo problema?

Answer 1

Come indicato in the documentation--relocatable è un'opzione sperimentale, quindi non sorprende che si stiano riscontrando difficoltà. Detto questo, ti sei ricordato di rieseguire --relocatable dopo aver installato nuovi pacchetti? Se hai installato i pacchetti da github con -e, questo potrebbe essere un problema, in quanto non viene installato nei pacchetti del sito, ma contiene anche i collegamenti simbolici. In alternativa all'utilizzo di --relocatable, di solito è possibile cancellare i file specifici di virtualenv e ricrearli in posizione (cosa che ho fatto un paio di volte quando si passa da una piattaforma all'altra).

Answer 2

No, per uno '--relocatable' non aggiorna lo script 'virtualenv/bin/activate'. Sì, è possibile risolvere il problema eseguendo nuovamente l'installazione di env virtuale come suggerito da zeekay, tuttavia non si riesce ad importare alcuna installazione "pip -e git ..." che viene inserita in "virtualenv/src", quindi sarà necessario eseguire nuovamente quei pip si installano manualmente.

Dall'esperienza ora un giorno non installo con pip editable (-e) e se necessario clonare manualmente i repository in "project/src /" in contrapposizione a "project/virtualenv/src" e avere il seguente script auto_prep_pythonpath.py caricato prima di avviare il mio progetto (lo faccio riferimento nel mio script django.wsgi).

Come nota a margine, aggiungo "su misura" a tutti i pacchetti inseriti in "project/src" che sono modificati/hackerati, quindi non devo preoccuparmi della compatibilità con le versioni precedenti e rintraccio tutta la sorgente sotto il controllo del codice come i repository online possono e ti freneranno.

Spero che questo aiuti.

""" 
Prepares python path to include additional project/src/<APP> in PYTHONPATH - This file gets automatically loaded by projects __init__.py 

This script lives in 'project/src/django-project/auto_prep_pythonpath.py', modify 
'SOURCE_ROOT' if you place it somehwere else. 
""" 
import logging 
import os 
import sys 
SOURCE_ROOT = os.path.dirname(os.path.abspath(__file__)).replace('\\','/') # the replacements are when on windows 
SOURCE_ROOT = os.path.join(SOURCE_ROOT, '../').replace('\\','/') 
SOURCE_ROOT = os.path.normpath(SOURCE_ROOT) 

logger = logging.getLogger(__name__) 

logger.info("Adding packages in 'src/*' required by project to PYTHONPATCH.") 
dirlist_arr = os.listdir(SOURCE_ROOT) 
while dirlist_arr: 
    item_path = os.path.join(SOURCE_ROOT, dirlist_arr.pop()).replace('\\','/') # replace dashes is for win based file system 
    if os.path.isdir(item_path): 
     if not item_path in sys.path: 
      sys.path.insert(0, item_path) # we use insert to take precedence over any global paths - minimises import conflict suprises 
     logger.debug("Path '%s' added." % item_path)