Repository navigation
Better interoperability with pipenv #114
Description
Problem
pipenv is a very popular manager for virtual environments and respects WORKON_HOME through pev, but environments created by pipenv end in a hash that causes it to be a little inconvenient to use virtualenvwrapper with pipenv.
Proposed Solution
workon should have an argument to determine the virtualenv directory from the current directory path, using the same logic as pipenv. I think it should be something like workon --pipenv.
Workaround
It isn't that hard if you already can write shell functions and import them when you launch your shell. My current one looks like this:
function workonenv ()
{
if [[ $# -ne 0 ]]; then
echo "Usage: $0" 1>&2;
return 1;
else
if [[ ! -f "./Pipfile" ]]; then
echo "./Pipfile: file not found" 1>&2;
return 1;
else
if [[ -n "$VIRTUAL_ENV" ]]; then
echo "do not use this command from within a virtualenv" 1>&2;
return 1;
fi;
fi;
fi;
ENV_NAME=$(python -c "from pipenv.project import Project; print(Project('.').virtualenv_name)");
HAVE_WORKON=$(type workon | head -1);
if [[ "$HAVE_WORKON" != "workon is a function" ]]; then
echo "virtualenvwrapper may not be active" 1>&2;
return 1;
fi;
workon $ENV_NAME
}Downsides with Workaround
The workaround isn't perfect. Because it isn't part of virtualenvwrapper, it is harder to carry it with me. It also doesn't recognize that this is different from a normal argument to workon:
$ workonenv
ERROR: Environment 'scrapeboa-L7gq2F0U' does not exist. Create it with 'mkvirtualenv scrapeboa-L7gq2F0U'.
$ pipenv sync -d
...
$ workonenv
(scrapeboa) $
Activity
carltongibson commentedon May 4, 2026
I think this should probably be closed. pipenv is (I think) now not really active.
Once PEP 832 (for better venv discovery) is resolved we might have work to do there: https://peps.python.org/pep-0832/