You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
functionworkonenv ()
{
if [[ $#-ne 0 ]];thenecho"Usage: $0"1>&2;return 1;elseif [[ !-f"./Pipfile" ]];thenecho"./Pipfile: file not found"1>&2;return 1;elseif [[ -n"$VIRTUAL_ENV" ]];thenecho"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" ]];thenecho"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) $
Problem
pipenvis a very popular manager for virtual environments and respectsWORKON_HOMEthroughpev, but environments created bypipenvend in a hash that causes it to be a little inconvenient to usevirtualenvwrapperwithpipenv.Proposed Solution
workonshould have an argument to determine the virtualenv directory from the current directory path, using the same logic aspipenv. I think it should be something likeworkon --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:
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: