Hey,

longtime listener, not-very-long-time member, once-writer here.

I just wanted to respond to the booster who sent in a hot take about Python packaging ecosystem being "a disaster" compared to Java, and how wonderful and trouble-free it was compared to Python's virtual environments. It made my blood boil just a little bit, because its one-sidedness was very reminiscent to me of fanbois back from when the Get the Facts campaign was making rounds. I have no doubts that the perception is fueled by this xkcd (https://xkcd.com/1987/), and it's memeable just as not being able to quit vim.

I fear, however, that the booster conveniently omitted how much of a clownshow it had been when the Log4j fiasco happened. The big problem with "set and forget" deployments which run with year-long uptimes and such is that it's very easy to start thinking about them as being fundamentally immutable, and when you actually have to mutate them, you often need to McGyver into the jars of jars of jars, because actually rebuilding and redeploying this stuff is nigh-impossible: the owner might have lost all the sources and dismantled the (likely expensive) build toolchain years ago, they are on v5 while they need to patch v1, and none of the current employees know their way around v1, etc.

And the most important thing: none of that packaging would give you a 100% iron-clad guarantee it could pinpoint all the places where the vulnerable log4j classes were tucked in. A transitive dependency of your transitive dependency. Several versions at once several jars down. All those talks of SBOMs only started seriously after most fires had been put out.

It has been a disaster which proves one thing: while software packaging is mostly a solved problem, the solutions ALL have varying levels of suckage. It's a complex problem which cannot have a simple solution, and I have doubts whether a truly universal solution may exist.

I might be biased because my full-stack work actually involves packaging things, and I've seen a lot of it.

---

AI SUM:


+ The author disagrees with a booster who claimed that the Java packaging ecosystem is "a disaster" compared to Python's virtual environments.
+ The author argues that the Java packaging ecosystem is not as trouble-free as the booster claims, pointing to the Log4j fiasco as an example.
+ The author believes that all software packaging solutions have varying levels of suckage, and that a truly universal solution may not exist.
    The author is biased because their full-stack work involves packaging things, and they have seen a lot of it.