Hacker News Reader

Comment by Townley | Hacker News Reader

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?

View on HN

> 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.

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.

"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.

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.

Reply on news.ycombinator.com