[ploxiln]

python3 includes "venv". If you don't have an existing preference, use that.

   python3 -m venv ../my-venv-dir # wherever you like
   . ../my-venv-dir/bin/activate
   pip install whatever

you can close your terminal and "rm -r" the venv dir, and no trace will be left. (or you can just "deactivate" and use it again later)

[virtualritz]

I was talking about the situation where you have to work on an existing codebase not where you start a Python project by yourself.

[mshockwave]

The author mentioned venv in the article. Also I believe the parent comment is talking about the difficulties of choosing between different dependencies management solutions, venv among them, rather than the lack of (a good) one

[blandcoffee]

Why cause yourself difficulty by drifting towards optionality vs. using the ops suggestion and using venv?

This topic gets posted to HN far too often - I'm starting to think people are deliberately avoiding venv for some reason, because otherwise it's a perfectly capable system for package management.

[wheelerof4te]

Yeah, many people here are suggesting poetry.

First (and last) time I've tried it, it was a complicated mess when compared to

python3 -m venv <venv_name>

[ploxiln]

Yes the article mentioned venv. And the parent said it's hard to choose. But the choice is easy: just use the basic built-in one. (Until you have a reason to use something else.)

It's a good general philosophy for software engineering: don't add stuff without good reason. There really is the potential to add infinite stuff these days - "awesome tools" and "best practices", without end. Individually they can help with particular problems you may have, but together they make a mess, and distract focus from the particular purpose of your software.

[pbalau]

I feel mischievous

    python -m venv node_modules