[jooz]

Ive heard that 'venv' are very problematic, but honestly, Ive never had a problem. And I used them daily. I understand that it can not be enough on some cases... that don't concern me.

I would recommend to 'python -m venv' and thats all.

[abrichr]

Agreed, never had a problem with this approach.

The only limitation I've encountered is when moving the environment or renaming one of the parent directories. In which case it's easy to create a new one:

    # optional: freeze the environment if you don't already have a requirements.txt
    source .venv/bin/activate
    pip freeze > requirements.txt
    deactivate

    # remove the old environment
    rm -rf .venv

    # create a new one
    python3.10 -m venv .venv

    # activate it
    source .venv/bin/activate

    # install the requirements
    pip install -r requirements.txt

[nicoburns]

I've found that venv's work. They're just very inconvenient (having to constantly manage which venv you're in when you change directory). Consider that with NPM, only two of those commands are ever needed:

    # install the requirements
    npm install

    # remove it
    rm -rf node_modules

The rest is unnecessary because NPM uses the equivalent of a venv automatically based on your current working directory and the location of your package.json file.

[pepa65]

This just illustrates that the most recommended solution is not easy to use, many steps one could forget. And I guess if your package manager happens to update your default python, more/other steps will be necessary...

[Groxx]

I've heard a lot (a lot) of complaints that are wildly misattributed to venv (like "version X of Y broke my project"), but I've essentially never heard of issues with venv itself.

Aside from needing to know to use it. Which is certainly a problem. But python blessing a single venv-system might be worse in the long run...?

[BiteCode_dev]

That's pretty much the take of the article this one references.

The whole reason I posted this one is to justify the "just use -m pip and -m venv" stance I wrote in the article 4 days ago.

Because you will always have a very vocal minority of people that will fill the threads with counter arguments actually increasing complexity and risks of failure.

[tetha]

This is one of the jenga towers that seem to hold up most reliably for me as well. (i) Use python installed via the package manager. (ii) If python is updated, wipe all venvs, because there can be strange interactions between venvs and the installed python and rebuilding venvs is cheap, and (iii) Work in venvs as much as possible.

[bobx11]

This is also my setup. It has the added benefit of being already included on every python install already so there is nothing extra to use.

[nagonago]

I'm curious what these problems are. The only problem I've had with venv is that sometimes I forget to activate it.

As the article says, I think these days it's pretty safe to just use Python's built-in venv and stay away from everything else.

[hobs]

Same no problem, different solution - I use pycharm extensively and it manages my venvs 99% of the time with no issues at all, the only time it took me a minute of head scratching was realizing I needed to install a new system python to make a venv with it, but that would be clear if you were doing it via the shell approach you are using as well.

[atemerev]

How do you manage python versions with venv? E.g. numba still doesn’t run on my system python 3.11, so I want a 3.10 somewhere, but can’t install it through a package manager, etc.

[0xDEFACED]

If using apt, you can add the deadsnakes repository which allows installing the other versions of python3 not included with your linux distro. Then you can install them with

  sudo apt install python3.X

I also recommend similarly

  sudo apt install python3.X-venv

which allows you to create venvs with whichever python version you have installed

  python3.X -m venv .venv