Better interoperability with pipenv

[danizen]

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) $ 

[carltongibson]

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/