explore running 'pipenv shell' automatically

[kennethreitz]

No description provided.

[kennethreitz]

this would have to be a 5.0 release, if we do it at all... i think it would be too magical, but at the same time, it might be really nice. i'd like to prototype it out maybe.

[jacebrowning]

If I'm understanding the description correctly, I have a use case for this.

pytest-watch is a tool that reruns py.test when files change, but pipenv run ptw doesn't work because pipenv's shell isn't activated when using the run command:

$ pipenv run ptw

Running: py.test
Error: [Errno 2] No such file or directory: 'py.test'

Related patch to make pytest-watch work with pipenv: joeyespo/pytest-watch#72

[Blue-Dog-Archolite]

I use a cheat to activate pipenv on cd. Not sure if its relevant here. I hack the bash cd and add some magic.

function cd {
    builtin cd "$@"
    if [ -f "Pipfile" ] ; then
        pipenv shell
    fi
  }  

[kennethreitz]

And for fish shell, we have a plugin now! https://github.com/fisherman/pipenv

[kennethreitz]

Anyone who wants such fanciness should be using fish anyway. Closing :)

[nikolak]

Just stumbled upon this issue while trying out pipenv. The reason for closing it is... weird, to put it nicely.

It'd be like saying "if you want better packaging tools don't use python, use some other language" instead of developing pipenv.

[jcrben]

I use https://github.com/pyenv/pyenv-virtualenv to automatically activate a virtualenv - maybe this project can leverage and integrate the work there?

Not real inclined to switch to fish - I've been messing with https://github.com/xonsh/xonsh more

[264nm]

@jcrben That's kinda where my train of thought was heading towards towards as well... wouldn't be too much of a stretch to modify it for pipenv by the looks of it.

[mattions]

@kennethreitz are you completely against this one?

Should we open a new issue, continue the the discussion here and re-opening this one, or something else?

I think the rationale has been explained properly, but I want to bring one more example:
I used pyenv since I switched to pipenv.
A nice feature of pyenv when using virtualenv was the automatic activation when changing to the directory which had a dedicated .python-version file in it.

this was extremely handy, especially when you deal with a lot of different projects in different status with different codes: you don't have to switch on the "right" environment, it is done for you, and it's one command less to run.

I think this should be done automatically by pipenv, as in the pyenv-virtualenv example. I'm even ok if we have to install an independent plugin, or we want to set some kind of configuration parameters that define the behaviour, so we are avoiding the magic, but it's a user choice. I will still support the case that it should be the default, and maybe only an opt-out option, however I think not a lot of people would like to drop this functionality.

[JohnVonNeumann]

How is automatically activating venv's "fanciness"? It's a basic operation that I don't want to be performing over and over, seems a bit flippant to just close this issue with what is effectively a "just migrate shell's LOL".

[uranusjr]

@JohnVonNeumann Well you would think this is a mundane and required feature, until you actually try to implement it. This is very difficult to implement without some terrible hacks (I consider pyenv’s shims terrible, in case you wonder). The operation may be basic (I don’t think so, in fact), but the work involved isn’t. Try it yourself first, and we can have a discussion after you come up with something. :)

[JohnVonNeumann]

@uranusjr Thinking and believing this is a mundane and required feature, and then also believing it should be in the product, shouldn't be impacted by the difficulty required to implement. We can agree on the usefulness of a proposed something before working out how to build it. This, I would imagine, is common engineering, you figure out what you want then build it, you don't create features because based on their ease of creation, you create features based on the benefits of them.

In saying this, if something is difficult to build, then so be it, that's the fact. What I find a little disconcerting however is that if this is the case, then people should say this. Not just "Ahh this would be hard, wouldn't be useful anyway". If I did this everytime I got handed a difficult ticket at work I wouldn't have a job.

And whilst I can appreciate the point you're trying to make here with your comments, and I would 100% love to help out with a feature like this because I'd get a lot of good practical use out of it, I'm a little chafed by your comment because it's like because I haven't built the thing myself, I'm not allowed an opinion. I'm not the only person to have brought this up, and in fact, from what I can see, we appear to be in the majority in our opinion. I thought OS was about community consensus? If help is required on a feature, ask for it, don't just veto it and act as if it wouldn't be useful.

[techalchemy]

This is out of scope for design reasons whether the implementation is easy or not. We have no plans of forcing people into subshells, that’s why we have pipenv run and a scripts section in the Pipfile.

[caioariede]

Just improved @Blue-Dog-Archolite's suggestion for my case. Here's my .zshrc:

function auto_pipenv_shell {
    if [ ! -n "${PIPENV_ACTIVE+1}" ]; then
        if [ -f "Pipfile" ] ; then
            pipenv shell
        fi
    fi
}

function cd {
    builtin cd "$@"
    auto_pipenv_shell
}

auto_pipenv_shell

[joaqo]

Hey thanks for the snippet @caioariede, I'm using it atm and its great. I made some slight modifications to it for my particular use case, I'm posting them here just in case someone else may find them useful.

Also added a couple of methods for managing of virtualenvs as I still cannot completely switch over to pipenv (pipenv shell is just too slow atm).

# Activate current folder's pipenv virtualenv
# or accept an explicit virtualenv name
workon() {
if [ $# -eq 0 ]
then
    source $(pipenv --venv)/bin/activate
else
    source ~/.virtualenvs/$1/bin/activate
fi
}

# Making virtualenv alias
mkvenv() {
cd ~/.virtualenvs
virtualenv "$@"
cd -
workon "$1"
}

# Automatic virtualenv sourcing
function auto_pipenv_shell {
    if [ ! -n "$VIRTUAL_ENV" ]; then
        if [ -f "Pipfile" ] ; then
            workon
        fi
    fi
}
function cd {
    builtin cd "$@"
    auto_pipenv_shell
}
auto_pipenv_shell

[techalchemy]

It would be great if someone could add a wiki entry for these!

[uranusjr]

I made one: https://github.com/pypa/pipenv/wiki/Run-pipenv-shell-automatically

[piotr-dobrogost]

Maybe https://github.com/MichaelAquilina/zsh-autoswitch-virtualenv could be inspiration for someone.

[ethanj]

Might I suggest the following (works in .zshrc and maybe .bashrc?):

# automatically run "pipenv shell" if we enter a pipenv project subdirectory
# if opening a new terminal, preserve the source directory
PROMPT_COMMAND='prompt'
precmd() { eval "$PROMPT_COMMAND" }
function prompt()
{
    if [ ! $PIPENV_ACTIVE ]; then
      if [ `pipenv --venv 2>/dev/null` ]; then
        export PIPENV_INITPWD="$PWD"
        pipenv shell
      fi
    elif [ $PIPENV_INITPWD ] ; then
      cd "$PIPENV_INITPWD"
      unset PIPENV_INITPWD
    fi
}

[uranusjr]

@ethanj Please add it to the wiki :) I added it.

[joaqo]

Hey @uranusjr thanks for adding the wiki entry! One small detail, you referenced me as @joapo instead of @joaqo

[uranusjr]

Fixed—really sorry about that.

[garyo]

I'm not sure if this is the right place, but I'm trying to switch to pipenv and finding it painful to have to switch to a subshell or prefix every command that might use python with "pipenv run". Using zsh, I have a fair amount of state in my shell -- history, dir stack, and other stuff, not to mention having to double-exit to exit the terminal or switch to a new virtualenv. Having to pop into a subshell to work normally is a lot worse than "source $(pipenv shell-vars)" would be. Has there been any thought given to implementing a "pipenv shell-vars" command so people can switch around in the same shell?

[deeuu]

I've created an auto-activator for xonsh

@uranusjr Would you consider adding the following to the wiki page?

# xonsh
[xontrib-apipenv](https://github.com/deeuu/xontrib-apipenv) by @deeuu

[john-sandall]

Maybe https://github.com/MichaelAquilina/zsh-autoswitch-virtualenv could be inspiration for someone.

This looks like it does the job quite nicely, as it "will also detect and auto activate virtualenvs made with pipenv". @uranusjr please could you add this to the wiki? In this case I prefer a well-documented community made solution to the custom bash/zsh solutions currently there.

[nicopauss]

Since I was not satisfy with the solutions proposed on the wiki page, I have created pipenv-activate: https://github.com/Intersec/pipenv-activate

pipenv-activate.sh is a POSIX shell script containing functions to manually or automatically activate and deactivate the virtual environment of Pipenv projects within the current shell.

Unlike pipenv shell, the virtual environment is directly loaded in the current Shell environment and thus it will not start a new sub-shell when the virtual environment is activated.

Similar to pipenv run or pipenv shell, when a .env is present, it will be loaded when the virtual environment is activated.

pipenv-activate is compatible and unit-tested with all POSIX shells, notably with bash, zsh, ksh, dash, ash.

It can be used as a plugin for oh-my-zsh and oh-my-bash.

It is used daily at Intersec by 60+ people without any issues.

It would be great to add it to the wiki page.

[uranusjr]

Thanks @nicopauss! I’ve added pipenv-activate to the wiki.