3 ms·

Curious about one criticism in particular: I can run pipenv shell to get a new shell which runs the activate script by default, giving you the worst of both

Curious about one criticism in particular: I can run pipenv shell to get a new shell which runs the activate script by default, giving you the worst of both worlds when it comes to virtualenv activation: the unwieldiness of a new shell, and the activate script, which the proponents of the shell spawning dislike. In a project that just uses pip + a virtual environment, I'm used to activating the virtual environment when I want to run a command. Why is `pipenv shell` any worse than that? What do "proponents of shell spawning" dislike about the activate command?

heavenlyblue 8y ago
What I don't really get is this: why can't you just prepend the virtualenv to the PATH and be good with it? That is only required obviously if you're using bash scripts which can't be directed to an actual python binary.
- pseudalopex 8y ago
  "activate" prevents accidentally nesting environments. It also changes the prompt to show which one is active. Running "deactivate" is easier than changing the environment variables back yourself.
  - JNRowe 8y ago
    Unless you change state yourself in the mean time. `deactivate` changes `$PATH` back to what it was when you ran `activate` for example, which isn’t likely to be what you want if you’ve changed it since. At least with a subshell you can know what state you’re returning to with <C-d>. That is part of the problem with the `virtualenv` story in my eyes. It offers the illusion of isolation, but falls down in quite a few ways which are annoying when they do pop up.
LyndsySimon 8y ago
> What do "proponents of shell spawning" dislike about the activate command? For me, it modifies my existing shell in ways that I don't fully understand. While I've never had any issues with that, I have experienced similar problems in the past with RVM and they were incredibly difficult to debug. Using the OS's tooling to create an isolated environment seems to fit much better with the "Unix philosophy" than modifying the existing one.

heavenlyblue 8y ago

What I don't really get is this: why can't you just prepend the virtualenv to the PATH and be good with it? That is only required obviously if you're using bash scripts which can't be directed to an actual python binary.

pseudalopex 8y ago
"activate" prevents accidentally nesting environments. It also changes the prompt to show which one is active. Running "deactivate" is easier than changing the environment variables back yourself.
- JNRowe 8y ago
  Unless you change state yourself in the mean time. `deactivate` changes `$PATH` back to what it was when you ran `activate` for example, which isn’t likely to be what you want if you’ve changed it since. At least with a subshell you can know what state you’re returning to with <C-d>. That is part of the problem with the `virtualenv` story in my eyes. It offers the illusion of isolation, but falls down in quite a few ways which are annoying when they do pop up.

LyndsySimon 8y ago

> What do "proponents of shell spawning" dislike about the activate command? For me, it modifies my existing shell in ways that I don't fully understand. While I've never had any issues with that, I have experienced similar problems in the past with RVM and they were incredibly difficult to debug. Using the OS's tooling to create an isolated environment seems to fit much better with the "Unix philosophy" than modifying the existing one.