Virtualenv: activate.sh échoue si l'option 'nounset' est définie

Créé le 7 juil. 2011  ·  24Commentaires  ·  Source: pypa/virtualenv

J'obtiens l'erreur suivante lorsque j'essaie d'activer un virtualenv.

$ source test-env/bin/activate
-bash: _OLD_VIRTUAL_PATH: unbound variable

Cela se produit parce que j'ai configuré Bash pour utiliser l'option _nounset_, qui génère une erreur lors de l'accès aux variables non définies (voir ici )

Commentaire le plus utile

Solution de contournement pour l'instant—

set -o nounset

[...]

set +o nounset
. ~/.env/bin/activate
set -o nounset

[...]

Tous les 24 commentaires

Je peux résoudre ce problème en modifiant cette ligne:
if [ -n "$OLD_VIRTUAL_PATH" ] ; then
pour:
if [ -n "${_OLD_VIRTUAL_PATH=''}" ] ; then
La construction ${VAR=DEFAULT} renvoie VAR si elle est définie, et DEFAULT si elle ne l'est pas (voir cette page . Nous pouvons alors utiliser la chaîne vide par défaut, provoquant le comportement attendu. C'est un peu moins lisible que je ne le souhaiterais, mais ça fait l'affaire.

En fait, c'est une solution boiteuse, car elle nécessite de réécrire tous les tests existentiels. Il est beaucoup plus facile d'ajouter simplement set -o nounset en haut du script.

J'ai frappé ça aussi.

Moi aussi

Je soupçonne que peut-être un moyen de désactiver le -u pour les entrailles du script, puis de le faire restaurer le paramètre d'origine lors de la finition aurait du sens.

J'essaie de trouver un moyen de le faire ici - http://stackoverflow.com/questions/13494841/how-can-you-ask-bash-for-the-current-options

Demande d'extraction faite - https://github.com/pypa/virtualenv/pull/357

Je ferais:

if [ -n "$OLD_VIRTUAL_PATH" ] ; then

pour:

if [ -n "${_OLD_VIRTUAL_PATH-}" ] ; then
${var-DEFAULT}  If var not set, evaluate expression as $DEFAULT *

Ouais, viens de frapper ça moi-même.

En cours d'exécution virtualenv==1.11.4 .

Solution de contournement pour l'instant—

set -o nounset

[...]

set +o nounset
. ~/.env/bin/activate
set -o nounset

[...]

Cela peut être corrigé par https://github.com/pypa/virtualenv/pull/723 , qui utilise if ! [ -z "${_OLD_VIRTUAL_PATH+x}" ] ; then .

Veuillez noter que $_OLD_VIRTUAL_PATH lui-même est destiné à être supprimé dans #722. Mais # 723 le corrige également pour les autres vars.

:+1:

je tape dessus aussi....

C'est un peu bizarre qu'un problème aussi simple ne soit pas résolu après quatre ans.
Le travail de beaumartinez est le plus simple pour l'instant.

Ceci est corrigé par #645.

Fixé

@dstufft pourriez-vous s'il vous plaît spécifier dans quelle version cela a-t-il été corrigé afin que nous puissions nous assurer que nous avons installé la version minimale nécessaire ? À partir du bogue, il n'est pas du tout clair quelle version inclut le correctif.

@ssbarnea Il a été corrigé le 12 août 2015, comme indiqué dans les commentaires ci-dessus, donc toute version publiée après cette date. De https://virtualenv.pypa.io/en/latest/changes/ cela signifie 13.1.1 (et en effet la note pour cette version mentionne spécifiquement ce changement). Toutes ces informations sont facilement disponibles, donc vous auriez probablement pu les trouver avec une brève recherche (c'est ce que j'ai fait).

J'ai de mauvaises nouvelles : ce bogue devrait être rouvert car maintenant j'obtiens activate: line 13: _OLD_VIRTUAL_PYTHONHOME: unbound variable et tout en corrigeant cela, je pense qu'il est essentiel d'introduire un test qui tente d'activer l'environnement virtuel en utilisant strict bash

Cela s'applique également à line 22: ZSH_VERSION: unbound variable ... et je me demande combien de temps la liste irait ... ma ligne de commande de contournement commence à paraître perverse :

PS1="${{PS1:-}}" _OLD_VIRTUAL_PATH="${{_OLD_VIRTUAL_PATH:-}}" _OLD_VIRTUAL_PYTHONHOME="${{_OLD_VIRTUAL_PYTHONHOME:-}}" source "$VENV/bin/activate"

Vous pouvez bien sûr simplement configurer l'environnement vous-même ou utiliser le chemin d'accès complet de l'exécutable Python.

Désolé de rouvrir la discussion à ce sujet, j'ai fait l'erreur de ne pas vérifier les versions de virtualenv que nous avions sur le serveur de build et j'ai fait une vilaine découverte, une ancienne version 1.10.1. Cela compterait pour beaucoup de bugs. Je vais le mettre à jour demain.

Aucune excuse nécessaire; En fait, j'ai appris quelques choses de cette reprise
conversation.

Le mar 7 mars 2017 à 15h09, Sorin Sbarnea [email protected]
a écrit:

Désolé de rouvrir la discussion à ce sujet, j'ai fait l'erreur de ne pas
vérifier les versions de virtualenv que nous avions sur le serveur de construction et je
a fait une découverte laide, une ancienne version 1.10.1. Cela compterait pour
beaucoup de bogues. Je vais le mettre à jour demain.


Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pypa/virtualenv/issues/150#issuecomment-284859700 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAFWbGU02kdSoecXUESrDHlOUN9Rci5Oks5rjcdvgaJpZM4AQ_Js
.

Il semble que le bogue existe toujours même dans la version actuelle, donc je l'ai signalé comme https://github.com/pypa/virtualenv/issues/1029

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