Reputation: 787
My application is writen in python 3, and I work in a virtualenv. On my cluster, there is hdp (hortonworks) installed and some scripts require python 2. Those script have #!/usr/bin/env python in the header, but it links to my python 3 installation because my virtualenv is activated. How to solve this ? I can't modify hdp source for obvious reasons.
Upvotes: 3
Views: 2143
Reputation: 295472
If you want your virtualenv to always be ignored with a #!/usr/bin/env python
shebang (but not with a #!/usr/bin/env python3
shebang), there's a big-hammer approach that prevents the python
entry in the PATH
added by the virtualenv from matching, but doesn't necessarily perform other cleanup:
rm "$VIRTUAL_ENV/bin/python"
...or a better-behaved alternative (assuming that you have a python2.7
in your PATH, and that it's what you want to use):
cat >"$VIRTUAL_ENV/bin/python" <<'EOF'
#!/usr/bin/env bash
path_prefix=$VIRTUAL_ENV/bin:
if [[ $PATH = $path_prefix* ]]; then
PATH=${PATH#$path_prefix}
fi
unset PYTHONHOME VIRTUAL_ENV
exec python2.7 "$@"
EOF
The below will assume you're looking for approaches with a bit more finesse.
If you interact with Hortonworks through a frontend called hdp
, consider the following a shell function, a wrapper for hdp
that deactivates the virtualenv:
hdp() (
if [[ $VIRTUAL_ENV ]]; then
deactivate
fi
exec command hdp "$@"
)
Because this function is using parentheses instead of curly braces, it runs in a subshell -- a separate copy of the shell environment -- so when it runs deactivate
, this doesn't impact your parent shell. This also means that the exec
command causes the subshell to replace itself with the hdp
command, rather than causing your parent shell to terminate.
If you want to be able to run other scripts with your virtualenv temporarily deactivated, consider instead:
# wv == "without virtualenv"
wv() (
if [[ $VIRTUAL_ENV ]]; then
deactivate
fi
exec "$@"
)
...such that wv foo
will run foo
with the virtualenv deactivated.
Upvotes: 3