virtualenv relocatable - ça marche vraiment

Question

J'ai continué à chercher une réponse mais je n'en ai pas trouvé. J'ai un répertoire env virtuel, un projet dir avec un req.txt. Lorsque je lance pip -r req.txt, il installe des applications de github (source) et certaines de pypi. Ceux de pypi sont très bien après un appel relocatable sur le evn virtuel, cependant les liens dans les paquets de site pour les applications qu'il a installées à partir de github pointent toujours vers l'ancien emplacement du répertoire.

Quelqu'un d'autre a vu ce comportement? Un moyen rapide autour d'elle? En outre, relocatable n'honore pas l'indicateur --no-site-packages qui a été utilisé sur virtualenv à l'origine. Une fois que vous déplacez le virtuel et le réactivez, tout est visible depuis les paquets de site du système. Docs indique ce comportement comme un fait, alors je me demande s'il y a un moyen rapide de contourner cela?

Answer 1

Comme indiqué dans the documentation--relocatable est une option expérimentale, il n'est donc pas surprenant que vous ayez des difficultés avec elle. Cela dit, vous souvenez-vous de relancer --relocatable après l'installation de nouveaux paquets? Si vous avez installé les packages à partir de github avec -e, cela peut être un problème, car il ne s'installe pas dans des packages de site, mais des liens symboliques dans celui-ci. Comme alternative à l'utilisation de --relocatable, vous pouvez généralement effacer les fichiers spécifiques à virtualenv et les recréer en place (ce que j'ai fait plusieurs fois en changeant de plateforme).

Answer 2

Non, pour un '--relocatable' ne met pas à jour le script 'virtualenv/bin/activate'. Oui, vous pouvez corriger cela en ré-exécutant l'installation d'env virtuel comme zeekay suggéré, mais cela ne réussit toujours pas à importer les installations 'pip -e git ...' qui sont placées dans 'virtualenv/src' donc vous devrez ré-exécuter ces pip s'installe manuellement. Par expérience maintenant quelques jours je ne pas installer avec pip modifiable (-e) et si nécessaire manuellement cloner les dépôts dans «projet/src /» par opposition à «projet/virtualenv/src» et avoir le script ci-dessous auto_prep_pythonpath.py chargé avant de lancer mon projet (je le référence dans mon script django.wsgi). En guise de note, j'ajoute 'customisé' à tous les paquets placés dans 'project/src' qui sont modifiés/piratés de sorte que je n'ai pas à m'inquiéter de la rétrocompatibilité et je fais le suivi de toutes les sources sous contrôle de code référentiels en ligne peuvent et vont freiner sur vous.

Espérons que cela aide.

""" 
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)