Python packaging is broken mostly because bootstrapping is broken, and it cascades to packaging but people don't know the bootstrapping is responsible and blame packaging.
Not saying packaging doesn't have faults, but on it's own, on a good Python setup, it's actually better than average. But few people have a good setup. In fact most people don't know what a good setup looks like.
Yes, that's one of the most important success of the tool. Being in rust, it is completely independent from the Python setup, and therefore it doesn't care if you botched it. And with the indy greg build, it can even avoid the pyenv pitfall of compiling on your machine on linux.
My single setup routine has served me well for years, with little to no change: pipx as the tools manager, miniconda for env bootstrap and management, poetry (installed with pipx) for project management (works great with conda envs) and autoenv to ensure the correct env is always active for any project I'm currently in. The only issue I may potentially have is if I install anything apart from Python via conda, as that won't be reflected in the pyproject file.
Because health is not a free market, if you are dying, you don't get to choose a competitor to your nearby hospital. Health is a lot of variation of that.
So the good part of capitalism don't work, but the bad parts do, like concentration of power and ignorance of externalities.
And today, we have reached a tipping point in those, with abuses overcoming people's tolerance for them.
LLM do Perl well enough, and since 90% of productivity with Perl is earned through small snippets or one-liners (anything bigger is better served with uv init --script), you can just ask the bit you want when you need it. You can even ask the AI to explain the hieroglyphs.
The ecosystem of PHP/Ruby/Python is miles ahead so if you need anything ranging from auth to validation, you will have to do 10 times the work.
In fact, even modern JS frameworks with features that have no equivalent in Laravel/RoR/Django see their appeal diminished because those old school frameworks do the basic so well they are productivity cheat code for essentials.
It's so easy to find people delighting in beautiful hot reload yet struggling for days making Oauth work or having to pay a saas for image resizing while 20 years old tech have that part nailed down.
The Mojolicious framework can do a lot of heavy lifting for you. It's not that hard to do interesting things while writing minimal code: https://www.mojolicious.org/
In this world and age of AI, having this kind of inside knowledge that is scattered, usually behind paywall and nda, and always to be updated, is a real advantage.
Because no LLM will be able to replace you for quite a while.
I rarely need it; now BT mice work quite well, but sometimes, to avoid pairing one mouse with a new device (and losing the previous one), I will use it.
Because HTMX is declarative and the declaration is in HTML, people have weirdly extended the "no need for js+json+rendering for ajax" to "don't use js".
This is making your life needlessly difficult.
HTMX is just a fancy ajax layer with a little event handling sprinkled on top. You can and should script to your heart content even if you use it, when you need so.
I use js in all most of my HTMX powered pages. Sometimes just a few lines. Sometimes a whole lot. Sometimes vanilla, sometimes alpine. I even have one where I load react for one single page because I want a community widget while the rest of the site is pure HTMX.
Of course you can combine the two but why use three tools (SSR + HTMX + JS) when I can just use two (SSR + JS)?
My point is that if you are going to use a JS framework then it will do the same as HTMX and I don't have to remember where to draw boundaries of responsibility.
that means you may be able to express more of your UI needs in HTML, using the traditional REST-ful architecture of the web (HATEOAS, in particular) and reserving JavaScript for the areas where that additional complexity adds the most value.
Depending on your application, this may lead to significant reduction in application complexity:
I concur, and this can be solved once you get the hang of actually creating a small bubble inside crowds and accept the FOMO of missing the rest of the event to have a quality conversation for a few hours.
Not everybody is made to ride a wave of people. But you can find a way to enjoy it in a different fashion. I find it true for a lot of situations, actually.
There's probably a certain unconference aspect to larger groups. (i.e. if something isn't working for you feel free to move on.) "This is really interesting but I really need to say hello to my friend over there who I haven't seen in ages." Of course, there's some art to politic transitions.
Not saying packaging doesn't have faults, but on it's own, on a good Python setup, it's actually better than average. But few people have a good setup. In fact most people don't know what a good setup looks like.
And here is why bootstrapping is broken: https://www.bitecode.dev/p/why-is-the-python-installation-pr...