3 ms·

I use python professionally and can't make sense of this comment. I'm doing my thing, running my ls, cd, greps and cats, and now I need to run my python cli....

I use python professionally and can't make sense of this comment. I'm doing my thing, running my ls, cd, greps and cats, and now I need to run my python cli.... And so I do pip install in which env exactly? The system one? Or do I have to create a venv just to install my python cli, and have to enable it every time I wanna run the cli? It's easy to say "just pip install", but I can't see how the details make sense in the context of a cli. Explain please?

password4321 5y ago
https://asdf-vm.com/ https://asdf-vm.com/ to the rescue! Well, maybe it's the latest in a long line of options...
- volker48 5y ago
  I started using asdf instead of homebrew for installing and managing Python and I haven't looked back. Asdf is infinitely better than homebrew python.
maleldil 5y ago
You can use pipx, which will create a new venv for each tool it installs. You call the program normally afterwards, and it will use the correct interpreter. There's not much wrong with just installing the tool to the global (user) interpreter, though.
SkipperCat 5y ago
Let's take the AWS CLI as an example. Run "pip3 install awscli --upgrade --user" and you're done. Drop the "--upgrade --user" and you've installed it globally. Easy Peezy. Sure, you can do a lot with venv, Anaconda and whatnot, but if you have a well written package, it can be very portable without the need of environments.
- ghjjiiffd 5y ago
  No, I don't wanna install random shit on the systems env
- lmz 5y ago
  What if you have two well written packages you want to use, with conflicting dependency versions?
  - SkipperCat 5y ago
    What if you have an old version of glib-c on your machine? There’s always going to be odd edge cases where things break, no matter what language you build your tooling, but I’ve installed thousands of Python packages on CentOS7, Ubuntu, OSX, Debian via pip and haven’t had issues. Ergo, I disagree with the writer. This article is basically saying “things are complex, complexity is hard, so don’t do complex things”. On that point I agree. If you don’t have the time to invest in the tech, don’t build unsupported systems. But don’t throw Python under the bus because you don’t have time to build a proper package.
- znep 5y ago
  Interesting example given you can no longer do that with the latest (v2) version of the AWS CLI, since it isn't published to PyPI due to how big of a nightmare AWS found supporting that to be. There is a very nice comment talking through some of the reasoning here that is worth a read: https://github.com/aws/aws-cli/issues/4947#issuecomment-586046886 https://github.com/aws/aws-cli/issues/4947#issuecomment-5860... I am quite annoyed v2 isn't in PyPI as it makes updating to v2 a sizable project in some cases and v1 does not support all services, but also quite understand their reasoning. Granted the tradeoffs may be weigh out differently for an internal tool as the post describes, or if distributing the tool to a more constrained audience.

password4321 5y ago

https://asdf-vm.com/ https://asdf-vm.com/ to the rescue! Well, maybe it's the latest in a long line of options...

volker48 5y ago
I started using asdf instead of homebrew for installing and managing Python and I haven't looked back. Asdf is infinitely better than homebrew python.

maleldil 5y ago

You can use pipx, which will create a new venv for each tool it installs. You call the program normally afterwards, and it will use the correct interpreter. There's not much wrong with just installing the tool to the global (user) interpreter, though.

SkipperCat 5y ago

Let's take the AWS CLI as an example. Run "pip3 install awscli --upgrade --user" and you're done. Drop the "--upgrade --user" and you've installed it globally. Easy Peezy. Sure, you can do a lot with venv, Anaconda and whatnot, but if you have a well written package, it can be very portable without the need of environments.

ghjjiiffd 5y ago
No, I don't wanna install random shit on the systems env
lmz 5y ago
What if you have two well written packages you want to use, with conflicting dependency versions?
- SkipperCat 5y ago
  What if you have an old version of glib-c on your machine? There’s always going to be odd edge cases where things break, no matter what language you build your tooling, but I’ve installed thousands of Python packages on CentOS7, Ubuntu, OSX, Debian via pip and haven’t had issues. Ergo, I disagree with the writer. This article is basically saying “things are complex, complexity is hard, so don’t do complex things”. On that point I agree. If you don’t have the time to invest in the tech, don’t build unsupported systems. But don’t throw Python under the bus because you don’t have time to build a proper package.
znep 5y ago
Interesting example given you can no longer do that with the latest (v2) version of the AWS CLI, since it isn't published to PyPI due to how big of a nightmare AWS found supporting that to be. There is a very nice comment talking through some of the reasoning here that is worth a read: https://github.com/aws/aws-cli/issues/4947#issuecomment-586046886 https://github.com/aws/aws-cli/issues/4947#issuecomment-5860... I am quite annoyed v2 isn't in PyPI as it makes updating to v2 a sizable project in some cases and v1 does not support all services, but also quite understand their reasoning. Granted the tradeoffs may be weigh out differently for an internal tool as the post describes, or if distributing the tool to a more constrained audience.