3 ms·
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/acti
by ploxiln 4y ago
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)
- mshockwave 4y agoThe 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 4y agoWhy 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 4y agoYeah, 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 4y agoYes 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 4y agoI feel mischievous python -m venv node_modules
- virtualritz 4y agoI was talking about the situation where you have to work on an existing codebase not where you start a Python project by yourself.