[skookum-skuad]

Yuck. The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages and GCing non-leaf packages. This pattern of "only one global package for everything" is failure. Too often, naïve designers will just cut things because they just don't understand them or copy & paste because they don't understand what failures exist and what solutions do/alternatives could exist.

Habitat (hab), nix, and others IIRC do SxS package mgmt.

Everything Should Be Made as Simple as Possible, But Not Simpler - possibly paraphrasing Einstein

[enriquto]

> The only way out of dependency hell is to disallow it by allowing multiple versions/different configurations of side-by-side packages (...)

Another elegant way, for a more civilized time, is to simply disallow dependencies. If none of your packages has any dependencies, then no dependency hell is ever possible. This is possible and easy with static executables (for binary packages), and by embedding the interpreter of packages written in scripting languages.

[catern]

Static binaries still have dependencies, they just embed them all into one file. That's not generically possible - as the most trivial example, consider a bash script which runs other executables. If you're trying to solve this problem, you need to actually solve it for all real cases; otherwise your solution breaks down and you're back where you started, in dependency hell.

[burpsnard]

This: perl ..

[mst]

App::FatPacker will turn your (pure perl) script and its dependencies into a single file for deployment.

App::staticperl will build a static binary with the perl+C dependencies built in.

A lot of the time, it's better to use a plenv + Carton, mind, but if you want a single file for deployment, that's a solved problem in perl land too and has been for years.