3 ms·

> Python -m venv in your project directory. Then source ./bin/activate. And how do I do that from inside an already running Emacs session? (Or Vscode?) Needin

> Python -m venv in your project directory. Then source ./bin/activate. And how do I do that from inside an already running Emacs session? (Or Vscode?) Needing to "prepare" an environment before you can work with it, prevents you from simply "jumping" into a task from an existing workflow. Working with .NET, Rust, Node, go, Haskell, etc... I have no such issues. This "venv"-requirement only applies to Python, and it's really the opposite of ergonomic. I really think it's about time the Python-community starts recognizing this.

thristian 6y ago
I generally recommend against `source ./bin/activate` for virtualenvs — it's convenient if you're using a single shell session interactively, but it plays quite poorly with the Unix process model of environment variables being inherited from parent processes to child processes. Instead, I recommend just running the other executables in the bin directory. `./bin/python` will drop you into a Python REPL with all the packages installed in that virtualenv available. Your IDE should let you specify what Python interpreter to use for running tests and other integrations; give it the path to that Python executable and everything should Just Work. Likewise, if your package uses setuptools entrypoints, they'll be installed into the bin directory too, and you can just run them with no further configuration. For what it's worth, Rust (for one) works pretty much the same way. The only difference is that Rust doesn't have a concept of dependencies installed system-wide, they're always handled per-project like venvs. As a result, they don't have decades of stale tutorials online telling people to do the wrong thing.
- regularfry 6y ago
  I usually give myself a `./exec` shell script that sources `./bin/activate` then `exec $SHELL $@`. That gives me a subshell with everything set up, so when I want out it's just Ctrl-D. Now that I'm used to the subshell idea, I use the same concept across ruby, node, and python; it's almost always a better fit than what the usual packaging tools give you. I don't need `bundle exec` in ruby, for instance.
disgruntledphd2 6y ago
In emacs, use pyvenv-activate. I think it's part of elpy.
dragonwriter 6y ago
> And how do I do that from inside an already running Emacs session? (Or Vscode?) From VSCode I just use the integrated terminal to create the venv, vscode's default python extensions recognizes in-process venvs by default and uses them. (The way it installs tooling is broken for them, though, but that's a bug in the extension.) Though it would be nice if Code integrated poetry so that just having a poetry-compatible pyproject.toml was sufficient. > Working with .NET, Rust, Node, go, Haskell, etc... I have no such issues. For most of those (Haskell with Cabal included), they have the same basic issue and solve it with a project file which is pretty similar in purpose and effect to poetry’s use of pyproject.toml.
nl 6y ago
VSCode will detect virtual environments within the directory structure. Node definitely has this issue. There's a reason Node NVM[1] exists. [1] https://github.com/nvm-sh/nvm https://github.com/nvm-sh/nvm
viraptor 6y ago
> Working with .NET, Rust, Node, go, Haskell, etc... I have no such issues. Respective solutions: NuGet, cargo, npm, go get, cabal. They all solve pretty much the same issue as venv and prepare your project in pretty much the same way. Raw venv can be a bit rough, but poetry solves that.
b5n 6y ago
Emacs: M-x pyvenv-activate Or in your init: (pyvenv-activate "~/code/python/venv_dir/emacs_venv") VSC: C-P Python: select interpreter It's pretty simple, and claiming nuget, node, and cabal/stack as superior means you're either lucky or inexperienced.

thristian 6y ago

I generally recommend against `source ./bin/activate` for virtualenvs — it's convenient if you're using a single shell session interactively, but it plays quite poorly with the Unix process model of environment variables being inherited from parent processes to child processes. Instead, I recommend just running the other executables in the bin directory. `./bin/python` will drop you into a Python REPL with all the packages installed in that virtualenv available. Your IDE should let you specify what Python interpreter to use for running tests and other integrations; give it the path to that Python executable and everything should Just Work. Likewise, if your package uses setuptools entrypoints, they'll be installed into the bin directory too, and you can just run them with no further configuration. For what it's worth, Rust (for one) works pretty much the same way. The only difference is that Rust doesn't have a concept of dependencies installed system-wide, they're always handled per-project like venvs. As a result, they don't have decades of stale tutorials online telling people to do the wrong thing.

regularfry 6y ago
I usually give myself a `./exec` shell script that sources `./bin/activate` then `exec $SHELL $@`. That gives me a subshell with everything set up, so when I want out it's just Ctrl-D. Now that I'm used to the subshell idea, I use the same concept across ruby, node, and python; it's almost always a better fit than what the usual packaging tools give you. I don't need `bundle exec` in ruby, for instance.

disgruntledphd2 6y ago

In emacs, use pyvenv-activate. I think it's part of elpy.

dragonwriter 6y ago

> And how do I do that from inside an already running Emacs session? (Or Vscode?) From VSCode I just use the integrated terminal to create the venv, vscode's default python extensions recognizes in-process venvs by default and uses them. (The way it installs tooling is broken for them, though, but that's a bug in the extension.) Though it would be nice if Code integrated poetry so that just having a poetry-compatible pyproject.toml was sufficient. > Working with .NET, Rust, Node, go, Haskell, etc... I have no such issues. For most of those (Haskell with Cabal included), they have the same basic issue and solve it with a project file which is pretty similar in purpose and effect to poetry’s use of pyproject.toml.

nl 6y ago

VSCode will detect virtual environments within the directory structure. Node definitely has this issue. There's a reason Node NVM[1] exists. [1] https://github.com/nvm-sh/nvm https://github.com/nvm-sh/nvm

viraptor 6y ago

> Working with .NET, Rust, Node, go, Haskell, etc... I have no such issues. Respective solutions: NuGet, cargo, npm, go get, cabal. They all solve pretty much the same issue as venv and prepare your project in pretty much the same way. Raw venv can be a bit rough, but poetry solves that.

b5n 6y ago

Emacs: M-x pyvenv-activate Or in your init: (pyvenv-activate "~/code/python/venv_dir/emacs_venv") VSC: C-P Python: select interpreter It's pretty simple, and claiming nuget, node, and cabal/stack as superior means you're either lucky or inexperienced.