Virtualenv: --relocatable ne pointe pas le script d'activation vers le bon chemin

Créé le 14 mars 2011  ·  14Commentaires  ·  Source: pypa/virtualenv

En utilisant Ubuntu 10.04, --relocatable fonctionne si j'invoque directement le binaire python ou les scripts générés par setuptools. Cependant, bin/activate reflète toujours l'ancien chemin :

> pwd
/home/jhammel
> virtualenv.py foo
New python executable in foo/bin/python
Installing setuptools............done.
> virtualenv.py --relocatable foo
Making script foo/bin/easy_install relative
Making script foo/bin/easy_install-2.6 relative
Making script foo/bin/pip relative
> mv foo bar
> cd bar
> . bin/activate
(foo)> echo $VIRTUAL_ENV
/home/jhammel/foo
(foo)> which python
/usr/bin/python
(foo)>

C'est parce que VIRTUAL_ENV est défini sur un chemin absolu dans le script. Au lieu de cela, cela devrait être relatif lorsque --relocatable est appelé.

Étant donné que le script activate doit être sourcé, il est un peu plus compliqué d'obtenir le chemin que (par exemple) dirname $0 . Ce qui suit semble fonctionner dans bash :

command=$(history 1) # this should go at the top of the file
parent_path() {
DIRECTORY=$(dirname ${!#})
cd $DIRECTORY/..
pwd
}
VIRTUAL_ENV=$(parent_path $command)

Si cela rencontre votre approbation, Ian, je suis heureux d'écrire un patch.


bug

Tous les 14 commentaires

désolé pour le mauvais formatage... bitbucket m'a encore trompé :(


Original Comment By: Jeff Hammel

Et %~dp0% pourrait être utilisé dans un environnement Windows pour obtenir le chemin d'accès au
script actuel, c'est-à-dire pour activate.bat.


Original Comment By: Sylvain Prat

Je pense que c'est une bonne idée, un patch serait génial.


Original Comment By: Jannis Leidel
  • Contenu modifié.

Original Comment By: Jannis Leidel

Voici une meilleure version pour bash :

VIRTUAL_ENV=$(cd $(dirname "$BASH_SOURCE"); dirname `pwd`)

Et pour (t)csh :

set sourced=($_)

set scriptdir=`dirname "$sourced[2]"`

set scriptpwd=`cd "$scriptdir"; pwd`

setenv VIRTUAL_ENV `dirname "$scriptpwd"`

Original Comment By: Anonymous

C'est ce que j'utilise :

VIRTUAL_ENV="$(dirname $(dirname $(readlink --canonicalize --no-newline

$BASH_SOURCE))))"

ou avec les options courtes

VIRTUAL_ENV="$(dirname $(dirname $(readlink -f -n $BASH_SOURCE)))"

Original Comment By: Matteo Bertini

Et une option pour ceux qui utilisent encore tcsh :

définir source=($_)
set scriptdir= dirname "$sourced[2]"
set scriptpwd= cd "$scriptdir"; pwd
setenv VIRTUAL_ENV dirname "$scriptpwd"

J'ai fait une pull request pour cette modification (qui implémente uniquement le script bash):
https://github.com/pypa/virtualenv/pull/143

Pour les fenêtres, dans ACTIVATE_BAT vous pouvez remplacer :

set VIRTUAL_ENV=__VIRTUAL_ENV__

avec:

pushd %~dp0..
set VIRTUAL_ENV=%CD%
popd

C'est mieux que de le définir directement sur %~dp0.. dans la mesure où vous vous retrouvez avec le même chemin absolu que vous le feriez sans le changement, mais il est déplaçable.

Ajout d'une référence au dernier numéro #1067 lié à cela pour aider à consolider les efforts sur la résolution de ce problème vieux d'une demi-décennie avec les scripts d'activation.

C'est ce que j'utilise :

VIRTUAL_ENV="$(dirname $(dirname $(readlink --canonicalize --no-newline

$BASH_SOURCE))))"

ou avec les options courtes

VIRTUAL_ENV="$(dirname $(dirname $(readlink -f -n $BASH_SOURCE)))"

L'utilisation de readlink peut être problématique, car elle a différentes options de ligne de commande entre Linux, BSD/macOS et potentiellement d'autres versions d'Unix.

@adah1972 , le numéro #1067 est le dernier. Ce numéro date de 2012, le #1067 date de 2017.

@arizvisa Merci. J'ai aussi commenté en #1067.

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Ajoutez simplement un commentaire si vous voulez le garder ouvert. Merci pour vos contributions.

Cette page vous a été utile?
0 / 5 - 0 notes