poetry: poetry shell does not activate virtualenv

Just in case someone else came googling for a quick but reliable temporary alternative that works in all shells:

# on .{bash,zsh,wtv}rc
alias poetry_shell='. "$(dirname $(poetry run which python))/activate"'

tl; dr — Move your pyenv and poetry configuration settings to ~/.bash_profile (make sure poetry configs come after pyenv’s) and out of ~/.bashrc if you’re using bash.

I got stuck on this issue in bash and the main issues seem to stem from the interaction of pyenv and poetry’s PATH-setting configuration found in my dotfiles:

# Initialize pyenv when a new shell spawns
eval "$(pyenv init -)"

# Modify path for Python's poetry dependency management system
export PATH="$HOME/.poetry/bin:$PATH"

I found that moving these scripts to ~/.bash_profile (as opposed to ~/.bashrc) helps resolve this issue. The problem in bash stems from the fact that ~/.bash_profile gets executed only on login (OS X registers new windows / panes as logins), whereas ~/.bashrc gets executed each time a shell is started. Because poetry shell is running a bash shell under the hood, it will also source ~/.bashrc (and therefore the pyenv script) when it is run, thus prepending pyenv’s shims to PATH after the virtual env is activated. By moving these configuration settings to ~/.bash_profile, we avoid this issue and the virtual env can prepend its path to PATH unfettered.

Anyone else find it odd that it’s so tricky to get a virtualenv up and activated? To me, that’s a main use case of poetry/pipenv/venv.

Came to file the same issue. My shell shows that a virtualenv is activated, but it’s empty; if I manually activate the .venv (installing locally to the project directory) then it works, but I would expect poetry shell to do that.

Maybe something like source "$(poetry venv)"? So, there would be no need in shell command.

This is my vote too 😀

Oh! The following is already supported in latest master at least - I think this is plenty.

source "$( poetry env info --path )/bin/activate"

This is more performant (relevant if you want to do something like ‘try/ensure’ virtualenv activated before every invocation of python, etc, in your scripts) –

[ -z "${VIRTUAL_ENV:-}" ] && source "$( poetry env info --path )/bin/activate"

So then IMHO all we really need is

1. small addition to the docs to suggest this usage pattern.
2. mark poetry shell for deprecation.
3. poetry should append export POETRY_ACTIVE=1 to activate script, upon any virtualenv creation. (otherwise poetry run will have POETRY_ACTIVE but not when you just source the activate script.)

This was still broken in 1.0.0b7, but has been resolved in 1.0.0b8 (and is still working in 1.0.0b9). Thank you.

@ziofil For fish, try: alias poetry_shell='. (dirname (poetry run which python))/activate.fish'

How would this work in the fish shell?

The shell command has been problematic from the start due to different shell configurations.

I think the best approach would be to stick with executing the virtualenv’s activate file for now until a better solution comes up.

Starting with poetry 1.0.0beta2 you can do:

source $(poetry env info -p)/bin/activate

If you’re on Poetry 0.12.x that doesn’t have env info but only debug:info, you can use:

source "$(poetry debug:info | rg '.*Path:[^/]+(.*)' -r '$1')/bin/activate"

(rg = ripgrep, though you could do it with grep and sed too)

or in alias form with escaping

alias activate=$'source "$(poetry debug:info | rg \'.*Path:[^/]+(.*)\' -r \'$1\')/bin/activate"'

The shell command has been improved in the latest 1.0.0 version and virtual environments should now be properly activated.

@dogweather That is not a constructive comment. You’re suggesting there’s some “natural” way to do this. There are many conflicting preferences people have about this.

If you want to add some detail to a usage, that’s constructive. For example, could you say if this works for you - currently it is, “source $(poetry env info -p)/bin/activate” if you want to just activate without going into subshell. (Or simply “poetry shell” if interactive subshell works for you). Don’t like this? Please be constructive in offering your take on a. more convenient workflow. “source $(poetry env activation)”? Etc.

Anyways, if that is your main use case, you should just look at autoenv and related. stdlib + venv is all you need if your comment is to be taken seriously.

Poetry/etc are about robust dependency management. Niceties about virtualenv are a small aspect. And keep in mind many of us want to use the same tools for multiple projects; too much “automatic assumptions for everyone” will hurt many multi-project use cases.

I know it’s hard to make a decision. Can you update docs to let users know this issue before it’s resolved? @sdispater

@sdispater senpai please note it’s actually pretty easy to make it work in a subshell for posix at least, there are only a few decisions to be made about windows compability and extra deps see https://github.com/sdispater/poetry/issues/497#issuecomment-443619684

Maybe something like source "$(poetry venv)"? So, there would be no need in shell command.

@wfa207 more details at https://github.com/sdispater/poetry/issues/198#issuecomment-430742299, which is linked from the (arguable duplicate of this issue) https://github.com/sdispater/poetry/issues/497.

I don’t have an activate script inside .venv/bin/

This is Poetry 0.12.10 installed via pip3 because of #721

In order to then get poetry shell to do anything I also had to pip3 install six attrs

poetry install --no-dev ran OK, I have a .venv in my project, but there’s no activate script at .venv/bin/activate

I am also experiencing this. I have all my setup opensourced, so one can follow all the steps of my zsh/pyenv/poetry shell madness. Here it is: https://github.com/sobolevn/dotfiles

Related parts:

• https://github.com/sobolevn/dotfiles/blob/master/shell/.exports#L22
• https://github.com/sobolevn/dotfiles/blob/master/shell/.exports#L62-L63

Things I have tried:

if [[ -z "$VIRTUAL_ENV" ]]; then
  eval "$(pyenv init -)"
fi

Now, it just ignores pyenv when new shell is created by poetry shell, but is still does not work as it should. Maybe we can have a look at how pipenv handles this? It is working for me.

I am experiencing this issue in Poetry version 1.0.2; poetry shell does not seem to activate the venv (I get eg. zsh: command not found: django-admin when trying to run django-admin), and running poetry shell a second time tells me it’s already activated but still django-admin is not found. But source .venv/bin/activate does work, and adds the (.venv) text to my command line prompt.

I use the setting that puts the venv in the local directory. The venv was created with poetry init.

I have some pyenv environment variable stuff in my .zshrc, and only this line in my .zprofile: export PATH="$HOME/.poetry/bin:$PATH"

Note I also have miniconda installed, though I don’t use it much.

I tried moving these two lines to before poetry’s stuff in .zprofile, and out of .zshrc:

export PATH="$(pyenv root)/shims:$PATH"
export PYENV_VERSION=3.6.4
export PATH="$HOME/.poetry/bin:$PATH"

But now if I run poetry shell I get this error due to not escaping my path that has a space in it:

(base) ➜  hue_app git:(master) ✗ poetry shell
Spawning shell within /Users/phoenix/Code/_personal projects/hue_app/.venv
Identity added: /Users/phoenix/.ssh/id_rsa_phoenix (/Users/phoenix/.ssh/id_rsa_phoenix)
(base) ➜  hue_app git:(master) ✗ . /Users/phoenix/Code/_personal projects/hue_app/.venv/bin/activate
.: no such file or directory: /Users/phoenix/Code/_personal

For those of you in a Windows shop, the following works in Powershell. I have something similar in my GitLab CI configuration to take advantage of the venv caching of poetry, among other beautiful things that poetry does

invoke-expression $($(poetry debug:info | sls Path | Out-String -Width 1000 | % {$_.replace("* Path: ", "").trim()}) + "\Scripts\activate.ps1")