Pipenv: `pipenv shell` with fish shell requires entering a command to complete

[antoine-gallix]

I have a small quirk when running pipenv shell with fish shell. When I run it, env var get loaded, and a subshell is spawned, but then it left me with a prompt, with a prepared activation command in it, the cursor at the end of the line, and I have to press enter again to activate the env.

~/path/of/work/dir > pipenv shell
Loading .env environment variables…
Spawning environment shell (/usr/bin/fish). Use 'exit' to leave.
~/path/of/work/dir > source /home/my-name/.local/share/virtualenvs/my-env-name/bin/activate.fish [cursor here and command ready to run]
# press enter
(name-of-my-env)   ~/path/of/work/dir >

I expect pipenv shell to work in one go, just as it does in bash. It's not a blocking problem, it just feels broken. And it prevents from automating too.

os: linux mint 18 cinnamon 64-bit
related ubuntu repo: Xenial 16.04
terminal emulator: terminator 0.98-1
fish: 2.7.1-1~xenial
Python: 3.6.5
pipenv: 2018.5.18

[uranusjr]

Sounds like a Fish-specific quirk… or is it environment-specific? I don’t use Fish at all and will need someone to verify.

In the mean time, does pipenv shell --fancy work for you? We (well, I) want to push its adoption if it does. The fancy alternative is so much less hacky than the default implementation.

[techalchemy]

Indeed that would feel broken. I use fish myself but I don’t have this issue, I would recommend using --fancy as suggested.

[antoine-gallix]

I've just tried pipenv shell --fancy and it doesn't seems to work:

~/path/of/work/dir > pipenv shell --fancy
Loading .env environment variables…
Launching subshell in virtual environment. Type 'exit' or 'Ctrl+D' to return.
~/path/of/work/dir > which python
/still/pointing/my/system/python

On the other side pipenv shell alone work, but with the quirk previously mentioned:

~/path/of/work/dir > pipenv shell
Loading .env environment variables…
Spawning environment shell (/usr/bin/fish). Use 'exit' to leave.
~/path/of/work/dir > source /home/my-name/.local/share/virtualenvs/my-env-name/bin/activate.fish [cursor here and command ready to run]
# press enter
(name-of-my-env)   ~/path/of/work/dir > which python
/now/pointing/to/the/virtualenv/python

Could it be that the two issues are related?

[uranusjr]

I honestly have no idea… activation is so environment-dependant and impossible to test :(

[antoine-gallix]

I understand. If there any check or test you would like me to try, I'm
willing to help.

[techalchemy]

if you can try against the current version of master it would be much appreciated

[antoine-gallix]

Sure, I just tried installing version 2018.6.26.dev0 but the issue persists

[techalchemy]

I think you're the only person experiencing this... you should set PIPENV_SHELL_FANCY=1 in your shell config so you can avoid this

[techalchemy]

(That is, I know why this is happening - we literally send the activation line to your terminal and run it; for whatever reason the running it aspect is not working for you)

[fanninpm]

What is the output from running pipenv --support, especially under the section that says Debug–specific environment variables:? I found that I had to change $SHELL from /bin/bash to /usr/local/bin/fish because I didn't know to set that up in my VSCode settings.json beforehand.

Hope that helps!

[antoine-gallix]

@techalchemy : pipenv shell --fancy or set -x PIPENV_SHELL_FANCY 1;pipenv shell both lead to the following two lines of output:

  ~/path/to/dir > pipenv shell --fancy
Loading .env environment variables...
Launching subshell in virtual environment…

And that's all. The environement doesn't get activated at all. No change in the prompt, which python points to the same python, pip list gives the list of my global packages, not the ones of virtualenv.

And for @fanninpm , here is the result of pipenv --support. SHELL is set to /usr/bin/fish

[uranusjr]

@antoine-gallix You probably need to upgrade to 2018.7.1 first. The dev version contains a PATH bug that might lead to this problem. I caught it at the last moment before releasing 2018.7.1 😛

The prompt not being changed is expected. Fancy people tend to configure their fancy prompts to be virtualenv-aware, and we don’t want to mess with that. To really tell whether you are inside shell, you need to check the SHLVL environment variable. It is incremented in every nested shell. Or you can become one of those fancy people (I’m not).

[antoine-gallix]

@uranusjr just upgraded to 2018.7.1. No improvements with using fancy mode or the normal mode. I can tell the virtual environement is not activated by looking where does point my python command (which python) and see what packages pip sees (pip list). It's not activated. Strangely, $SHLVL is incremented.

[uranusjr]

So the shell is launched successfully, but the PATH injection (which is done almost directly before the launch). This is very, very curious. I have no words… 🤯

[uranusjr]

Just to be sure, does the virtual environment appear in your $PATH?

[ijanos]

I'm using fish shell as well, and for me the normal shell command fails with the following error:

$ pipenv --version
pipenv, version 2018.7.1
$ pipenv --shell
~/.local/share/virtualenvs/py-BzEjMykm/bin/activate (line 23): Unsupported use of '||'. In fish, please use 'COMMAND; or COMMAND'.
    if [ -n "${BASH-}" ] || [ -n "${ZSH_VERSION-}" ] ; then

But using --fancy works fine.

$ pipenv shell --fancy
Launching subshell in virtual environment…
$ which python 
/home/ij/.local/share/virtualenvs/py-BzEjMykm/bin/python

I did not found fancy mode in the documentation, stumbled on it mentioned here in this issue when I came here to report the error. May I ask why is it called fancy? Making it default would definitely help with fish shell.

[uranusjr]

@ijanos First of all, this is totally unrelated with the original issue. Please open a separate entry if (and only if!) the followings don’t help.

Does env SHELL=/absolute/path/to/fish pipenv shell work? If so, Pipenv is failing to detect your environment. This will be improved in the next version. Please report back if it is not improved after a newer version drops.

--fancy used to be the fedault, and so many people came complaining we have to flip the switch and make it optional. It is called fancy because only cool people configure their shells correctly to make --fancy work. Cool people need to sacrifise here, unfortunately, because we are the minority, and at least have the ability to read help messages and documentation.

There is an environment variable to set pipenv shell to always operate in fancy mode, I must add. But you must have already read this from documentation, because you are one of those cool people!

[bkelemen56]

Not sure if another issue was opened for this, but I solved @ijanos issue by adding to config.fish:

set -x SHELL=/path/to/fish

as fish was not changing this variable from my default bash setting.

[ijanos]

Thank you for the suggestion, SHELL was set properly in my case.

[Qinusty]

virtualenvs provide activate.fish for use with fish.

. /home/<user>/.local/share/virtualenvs/<venv>/bin/activate.fish works as expected.

[zanchey]

(hello, I'm one of the fish committers)

I can't reproduce the originally-described problem (the source line is left in the command buffer, awaiting the enter key) here on macOS with pipenv, version 2018.11.26 and fish 3.0.0.

My guess with the problems with $PATH is that you are changing the path variable in your config.fish, and perhaps those lines should be guarded by if status is-login or similar.

[techalchemy]

Thanks for the update @zanchey and thanks for your work on the fish shell. I'll go ahead and close this issue now since nobody has managed to reproduce it, thanks all for the help digging into this and hopefully it doesn't reappear again!

[deanjones]

For others arriving here, I had the same problem as this, except in bash. I tracked the problem down to the following entry in my .bash_profile:

bind 'revert-all-at-newline on'

Removing this fixed the problem for me (it was clearly a local issue, so I just tried removing each line in my .bash_profile in turn).