4 ms·

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

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.

ydnaclementine 6y ago
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
- easton 6y ago
  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.
- thewrinklyninja 6y ago
  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 https://metacpan.org/pod/Carton
- viraptor 6y ago
  If you prefer "bundle exec foo", then "bin/python -mfoo" is pretty much the equivalent and doesn't require running activate before.
kevin_thibedeau 6y ago
Debian already has system packages isolated from user-installed with the dist-packages directory. It is less necessary to manage your own environment.
josteink 6y ago
> 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
zelphirkalt 6y ago
… 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.

ydnaclementine 6y ago

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

easton 6y ago
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.
thewrinklyninja 6y ago
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 https://metacpan.org/pod/Carton
viraptor 6y ago
If you prefer "bundle exec foo", then "bin/python -mfoo" is pretty much the equivalent and doesn't require running activate before.

kevin_thibedeau 6y ago

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

josteink 6y ago

> 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

zelphirkalt 6y ago

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