Hacker News Reader

Comment by CapriciousCptl | Hacker News Reader

Python -m venv in your project directory. Then source ./bin/activate. Pip install from the project directory as your regular user (no sudo). You can also set up venv (virtual environments) in home or somewhere else instead of for each project. This is called python virtual environments and very easy to adopt.

View on HN

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

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.

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.

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

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

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

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

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.

Ruby has this figured out well by comparison. Install the bundler gem (which you're going to be installing anyway to get dependencies), cd into the project, and prefix your commands with `bundle exec` to use project gems

Remembering to start/stop virtualenv and remembering the names of your virtual envs is one too many steps

Or just use poetry/pipenv shell (or poetry/pipenv run for one-off commands). Both provide a good wrapper, although poetry seems a bit more stable these days.

Perl has copied this as well with Carton. Works really well and as standard keeps the modules in the project dir.

https://metacpan.org/pod/Carton

If you prefer "bundle exec foo", then "bin/python -mfoo" is pretty much the equivalent and doesn't require running activate before.

Debian already has system packages isolated from user-installed with the dist-packages directory. It is less necessary to manage your own environment.

… and itis a non-reproducible setup.

The issue here is, that you are not storing hashsums and therefire are not safe.

To store hashsums you need a frozen requirements file, which needs another puthon lib … at this point it might be easier to use Poetry or Pipenv.

Reply on news.ycombinator.com