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

[sureglymop]

Python has this too, check out PEP 582. There's a package manager called PDM which will just create a __pyoackages__ folder in this style.

[rami3l]

As a PDM enthusiast for quite a while, I'm sorry to inform you that PEP 582 has been officially abandoned (which doesn't mean that it won't be revived someday, just not so easily). https://discuss.python.org/t/pep-582-python-local-packages-d...

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

[abrichr]

Venvs are self contained python environments, no interaction with system python.

For those already familiar with venvs, the above just condenses to “remove the old venv and create a new one”.