virtualenv: activate may fails due to unbound variables when run with set -eu
It seems that an old bug is still here: PS1: unbound variable when called with bash strict mode.
Clearly virtualenv needs a test using bash strict mode and an almost empty set of environment variables, so we avoid future regressions on this.
Please note that this bug does reproduce with ANY supported Unix shell, not only bash, including ksh and zsh.
Here is a simple way to replicate the bug:
#!/bin/bash
# same applies to any other bourne compatible shells (is not bash specific)
set -euox pipefail
pip install -U virtualenv
virtualenv xxx
unset PS1
source xxx/bin/activate
The workaround, while ugly, is to do prepend PS=${PS:-} to the activate line, which defines PS as empty string when is not already defined, or keeps its value when is defined.
The same kind of bug applies to Python version of venv and there is an already open PR to fix it there too.
Please do not postpone/delay implementing a fix just because the same kind of bug exists in other places. Note that the default expansion variable syntax is POSIX compatible and not something new or fancy, the fact that this was not known to the original author should not be an excuse for not using it.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 17
- Comments: 26 (7 by maintainers)
Commits related to this issue
- Avoid activate failure with unbound variables When shell (bash or compatible) is run with `set -ue` mode, activate can fail due to unbound variabled. Fixes #1029 Change-Id: I764297341dee69a01bd404... — committed to ssbarnea/virtualenv by ssbarnea 7 years ago
- Avoid activate failure with unbound variables When shell (bash or compatible) is run with `set -ue` mode, activate can fail due to unbound variabled. Fixes #1029 Change-Id: I764297341dee69a01bd404... — committed to ssbarnea/virtualenv by ssbarnea 7 years ago
- Avoid activate failure with unbound variables When shell (bash or compatible) is run with `set -ue` mode, activate can fail due to unbound variabled. Fixes #1029 Change-Id: I764297341dee69a01bd404... — committed to ssbarnea/virtualenv by ssbarnea 7 years ago
- Avoid activate failure with unbound variables When shell (bash or compatible) is run with `set -ue` mode, activate can fail due to unbound variabled. Fixes #1029 Change-Id: I764297341dee69a01bd404... — committed to ssbarnea/virtualenv by ssbarnea 7 years ago
- Workaround for virtualenv issue with old variables When running this script in terminal, it fails with errror _OLD_VIRTUAL_PATH, _OLD_VIRTUAL_PYTHONHOME is unbound. when activating virtualenv. Seems ... — committed to openstack/tripleo-ci by sshnaidm 7 years ago
- Update git submodules * Update tripleo-ci from branch 'master' - Merge "Workaround for virtualenv issue with old variables" - Workaround for virtualenv issue with old variables When runn... — committed to openstack/openstack by deleted user 7 years ago
- Avoid activate failure with unbound variables When shell (bash or compatible) is run in strict mode, activate can fail due to unbound variabled. Includes alternative sed call that is cross GNU/BSD c... — committed to ssbarnea/virtualenv by ssbarnea 7 years ago
- Update virtualenv.wdl There were a few issues: set -Eeuxo pipefail was not allowing bin/activate to work properly. See this: https://github.com/pypa/virtualenv/issues/1029. That was removed. Then ch... — committed to chopdgd/bfx-tools-wdl by genomics-geek 5 years ago
I’ve also been bitten by this, when working on the build script for an AWS lambda-based image processing solution: https://github.com/awslabs/serverless-image-handler/blob/master/deployment/build-s3-dist.sh
I’ve used the
VIRTUAL_ENV_DISABLE_PROMPT=true source env/bin/activateworkaround.FWIW, the workaround I’m using in .devkit is to set
VIRTUAL_ENV_DISABLE_PROMPT=trueon thesourceline. It works better for my use case than settingPS1, because it disables the prompt-setting behavior altogether.I am wondering how many years it would take to learn how to write bash code… the unbound variable bugs in virtualenv are eons old and so easy to fix and to also AVOID them in the future by just adding a simple line to the virtual tests:
set -euox pipefail.Not to mention how many years it will take for the fix to reach all virtualenv distros around there as that’s usually packaged on debian, ubuntu, centos, rhel, fedora, … 😦 😦 😦
I am also finding this, running virtualenv 15.1.0. I’m using an environment within a Nextflow pipeline, and Nextflow runs in strict mode by default (https://github.com/nextflow-io/nextflow/issues/302). While Nextflow can be reconfigured to run without strict mode, I agree with the Nextflow developer that it would be preferable to avoid using unbound variables, if possible.
I’m not sure exactly how the
activatescript is created, but if it comes from activate.sh, then the fix might be as simple as changing$PS1on lines 57, 59 and 61 to${PS1-}. (This syntax will use the value ofPS1if available, and the empty string otherwise. It doesn’t change the value ofPS1. Documentation). At least, if I modify the generatedactivatescript in my environment like this, the error message goes away.Ubuntu 16.04
Can we please get an ETA on when this will be merged and publicly available?
Edit: Still getting this issue, and it just brought down a build this morning.