Hacker News Reader

Comment by jddioeow | Hacker News Reader

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?

View on HN

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.

https://asdf-vm.com/ to the rescue!

Well, maybe it's the latest in a long line of options...

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.

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.

What if you have two well written packages you want to use, with conflicting dependency versions?

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.

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

Reply on news.ycombinator.com