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) $
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Problem
pipenv
is a very popular manager for virtual environments and respectsWORKON_HOME
throughpev
, but environments created bypipenv
end in a hash that causes it to be a little inconvenient to usevirtualenvwrapper
withpipenv.
Proposed Solution
workon
should 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:
The text was updated successfully, but these errors were encountered: