Not sure if I agree about the Python jab. I've seen "pip install ...." run flawlessly more times than I've had breakfast cereal, and I eat a lot of cereal.
I kinda agree on his first point about migrating stuff to the cloud but if you've done your deployments on like-like platforms (on prem containers to cloud containers) its not that bad.
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?
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.
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.
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.
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.
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.
I kinda agree on his first point about migrating stuff to the cloud but if you've done your deployments on like-like platforms (on prem containers to cloud containers) its not that bad.