I love when I look up a project and it's like "okay to build this, install poetry" and I click poetry and it goes "poetry should be installed with pipx" and I click pipx and it says "on windows, you should install pipx with scoop" so I click scoop and then my brain melts out my ears because this is too many layers deep
@foone A similar feeling to how I feel about many Java build systems.

Turns out the way many Guix packages do it is to just figure out what needs to be built and how, and then completely bypass the nonsense build systems (some of them seemingly don't even support any method of offline operation, they have achieved total conflation of dependency resolution language package manager (ewww) and build system).
@lispi314 @foone Guix is a wonderful island of respite from the M×N package managers problem
@ryanprior @foone I would imagine other distro package managers do it similarly because I really cannot see the labor being tractable any other way.
@lispi314 @foone I'm working on something in this space 
@ryanprior @foone JavaScript is one of those cases that has it worse than Java, because it took the language so long to have some standard manner of dealing with imports & such that the Java-like approach isn't actually usable with the majority of it.
@lispi314 @foone JavaScript, golang and rust are all victims of language package managers that work with too little friction, in my view. Python and Java have more humane package commons because the package managers are obnoxious to work with, so people don't want to pull in 5000 transitive package drops to do something routine

@ryanprior @foone In my opinion the problem starts at the conflation of dependency resolution and build systems.

The introduction of build systems with resolution builtin promptly reduces the friction of introducing spurious, dangerous and unnecessary dependencies to the point that short of already knowing better most will simply not have the time to think about it (Golang is big on this, but this is an issue I've noticed in a lot of IDE-centric languages).

(It also de-incentivizes proper packaging so it promptly gets left to the wayside, compounding the issue.)

Most original Java build systems had no such resolution at all and it shows in the language design (although this could be a chicken & egg thing and I'm reversing causality).

Python I think was coasting on inertia of other languages doing it right, since I think it did technically have resolution built-in from the start.