Pipenv: Add an equivalent of `workon` from virtualenvwrapper

[mjtamlyn]

Workon does two things. When executed with no args, it lists all available projects (i.e. venvs).

More helpfully, it streamlines the activation process when opening a new shell. This is super useful if you have dozens of projects you work on regularly. A possible syntax for pipenv could look like this:

~ $ pipenv work
blog
django
requests
supersecretproject
pipenv
~ $ pipenv work requests
Moving you to the requests project and activating the shell
(requests) ~/code/requests $

(PS1's might not be right for pipenv behaviour, but you get the idea.

This streamlines the developers' flow from:

cd code/requests
pipenv shell

to just:

pipenv work requests

It's a minor enhancement but something I'd miss moving from virtualenvwrapper.

[kennethreitz42]

I like this idea — it would automatically CD into the directory for you, too.

Unfortunately, we don't keep that information around in the virtualenv. We could add it, but it would only work on new virtualenvs going forward...

[kennethreitz42]

Also, would need to think of what would happen if there are two directories called 'requests'.

[kennethreitz42]

[kennethreitz42]

[kennethreitz42]

okay ready

[kennethreitz42]

got really close to this working — but it was too slow to crawl the directory structure.

[kennethreitz42]

Tabling it for now — thanks for the idea!

[piotr-dobrogost]

it was too slow to crawl the directory structure.

How about using WORKON_HOME environment variable and looking for virtualenvs only there? This way there would be no need to crawl.

[techalchemy]

We do this already for anything managed by pew.

On Oct 20, 2017, at 4:03 AM, Piotr Dobrogost [e-mail] wrote:

it was too slow to crawl the directory structure.

How about making use of WORKON_HOME environment variable and looking for virtualenvs only there? This would give workon command for all people used to it from virtualenvwrapper.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[erinxocon]

@techalchemy is correct. This is the default with pew.

[tuukkamustonen]

How about just maintaining index file (in ~/.pipenv/ or something)? You should support projects with PIPENV_VENV_IN_PROJECT=1 also, and simply looking at WORKON_HOME is not sufficient for that anyway.

[techalchemy]

It will be sufficient for that in the next release where we use temporary environments to make a modification to WORKON_HOME when using VENV_IN_PROJECT with pew.

On Oct 23, 2017, at 3:03 AM, Tuukka Mustonen [e-mail] wrote:

How about just maintaining index file (in ~/.pipenv/ or something)? You should support projects with PIPENV_VENV_IN_PROJECT=1 also, and simply looking at WORKON_HOME is not sufficient for that anyway.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[tuukkamustonen]

@techalchemy Do you mean that you write symlink or something to WORKON_HOME even with VENV_IN_PROJECT?

[techalchemy]

No. I mean what I said.

    try:
        with temp_environ():
            if PIPENV_VENV_IN_PROJECT:
                os.environ['WORKON_HOME'] = project.project_directory

            c = pexpect.spawn(
                cmd,
                args,
                dimensions=(
                    terminal_dimensions.lines,
                    terminal_dimensions.columns
                )
            )

    # Windows!
    except AttributeError:
        import subprocess
        # Tell pew to use the project directory as its workon_home
        with temp_environ():
            if PIPENV_VENV_IN_PROJECT:
                os.environ['WORKON_HOME'] = project.project_directory
            p = subprocess.Popen([cmd] + list(args), shell=True, universal_newlines=True)
            p.communicate()
            sys.exit(p.returncode)

[ashwinvis]

If this is working, why is there no open pull request on this feature @kennethreitz?

[filipweidemann]

@kennethreitz Is this feature still a thing? I really love Pipenv and recently converted all my projects, but an equivalent to virtualenvwrapper's workon would really add that last bit of luxury to it. You should consider adding it ;)

[kblicharski]

I'm also interested in this -- workon support would be a great convenience.

[kennethreitz42]

I prototyped it out, but it's not feasable, unfortunately. Rely on pew's functionality for this.

[ashwinvis]

@kennethreitz @fweidemann14 @kblicharski,
I finally understood. Here is a short rosetta, for someone who is as new to pew and pipenv as me.

| virtualenvwrapper + pip | pew + pipenv |
-----------------------------------|---------------------
| mkvirtualenv | pew new |
| cpvirtualenv | pew cp |
| lsvirtualenv | pew ls |
| workon | pew workon |
| deactivate | Ctrl + D / exit |
| pip install | pipenv install |

A few gotchas:

• The cdproject equivalent from virtualenvwrapper is missing. But pew setproject can do the change to directory once.
• pew new does not have a --system-site-packages option. Instead there is a separate pew toggleglobalsitepackages command.

[jtratner]

This would be a great table to add to the docs :)
On Tue, Feb 27, 2018 at 10:47 PM Ashwin Vishnu [e-mail]
wrote:

@kennethreitz https://github.com/kennethreitz @fweidemann14
https://github.com/fweidemann14 @kblicharski
https://github.com/kblicharski,
I finally understood. Here is a short rosetta, for someone who is as new
to pew and pipenv as me.
virtualenvwrapper + pip pew + pipenv
mkvirtualenv pew new
cpvirtualenv pew cp
lsvirtualenv pew ls
workon pew workon
deactivate Ctrl + D / exit
pip install pipenv install

A few gotchas:

• The cdproject equivalent from virtualenvwrapper is missing. But pew
  setproject can do the change to directory once.
• pew new does not have a --system-site-packages option. Instead there
  is a separate pew toggleglobalsitepackages command.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/535#issuecomment-369138703, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjqx5S5S0T_atTJnQi6UpGF-8XPikcks5tZPaDgaJpZM4PWVYT
.

[jasonslay]

What would be the workflow for using pew with pipenv? With virutalenvwrapper, mkproject and workon would get your virtualenvs configured and cd to your project. I see that pipenv and pew have some overlap - which command should I be using to create the virtualenv? Should I use pew add from inside a pipenv shell? I'm new to pipenv and love it so far. Just missing the workon functionality.

[jtratner]

Pipenv handles virtualenv creation for you, so you just use pipenv install to create the env, then pipenv shell to get an environment or
pipenv run <COMMAND> to do something in the shell
On Fri, Mar 2, 2018 at 2:55 PM Jason Slay [e-mail] wrote:

What would be the workflow for using pew with pipenv? With
virutalenvwrapper, mkproject and workon would get your virtualenvs
configured and cd to your project. I see that pipenv and pew have some
overlap - which command should I be using to create the virtualenv? Should
I use pew add from inside a pipenv shell? I'm new to pipenv and love it so
far. Justing missing the workon functionality.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/535#issuecomment-370078004, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq96a3RkHgh99kZ4CEJU4PMkbC-wEks5tac32gaJpZM4PWVYT
.

[jasonslay]

Apologies. I was referring to how to use pipenv with pew to replace the functionality of virtualenvwrapper. pew also creates virtualenvs. What is the workflow for using these packages together?

[gtalarico]

To anyone who might interested, I started a light pipenv companion to help do some of the work done by workon and cdproject.

Unlike pew, it does not attempt to manage your venvs in any way. All it does is it walks WORKON_HOME folder and provides a quick way of activating the created venvs, and cds into the project directories.

~Venv <> project dir linking is currently done manually, similar to setprojectdir but it will be automatic once PR #1861 is merged + released.~ PR Merged

https://github.com/gtalarico/pipenv-pipes

[filipweidemann]

@gtalarico Now this is exactly what I wanted Pipenv to do, great effort mate. Going to use it for sure!

[Peibolvig]

If anyone is interested in a more virtualenvwrapper way, I created pipenvwrapper

I tried pipes and pew and both are very good tools, but not the exact tools I was looking for my workflow, so I built pipenvwrapper using the base code of virtualenvwrapper.

The supported functions (simplified in some cases and no hooks support) are workon, lsvirtualenv, cdproject, cdvirtualenv, cdsitepackages, mkproject and rmvirtualenv.

"Workon" works with the venvs in $WORKON_HOME folder only, as virtualenvwrapper does.

To allow pipenvwrapper coexistance along with virtualenvwrapper, the function names have been renamed, but if you prefer the original ones and override virtualenvwrapper, you can do so setting an env variable in the shell startup file.

https://github.com/Peibolvig/pipenvwrapper

[techalchemy]

I’d be interested in someone convincing Kenneth (via an enhancement proposal) to allow some kind of plugin framework adoption, maybe via pluggy? No idea if that would work here, but I might put something together or provide feedback