> Unfortunately it is not a problem for nix to solve, they can’t really mandate upstream projects to not include hardcoded executables. Yet it's normal for Lin

> Unfortunately it is not a problem for nix to solve, they can’t really mandate upstream projects to not include hardcoded executables. Yet it's normal for Linux distros to patch upstream so that it works well inside of the distro. You may say "but that's crazy! Downstream patching Node packages opens up a whole can of worms!" Maybe you would be right--or maybe not. My point is that when I would raise these kinds of issues, I was met with a collective shrug or various justifications for why brokenness is actually a good thing. That's what I call a kind of academic/purist mentality that's really great for a research project and not practical for a product. If you ship a Linux distro (and note, I'm talking here about NixOS, not just Nix) that comes with software in the repo, the universal expectation is that the software works as intended, and if it doesn't that it's a bug. There can be an argument over whether the bug is upstream or downstream, but the fault is recognized. That recognition doesn't seem to happen in Nix world in cases where the package comes from an ecosystem that has assumptions that contradict Nix's (or NixOS') assumptions. > So I would even wager that without some language-specific help nix can’t really work seamlessly across other dependency managers. The thing is, Nix provides various helper functions to aid in writing derivations for packages from the different ecosystems. They actually try to adapt to the various idioms, which is admirable. My gripe is that each set of adaptations for each different ecosystem has its own entirely unique API. There's no meta-framework or set of common practices for writing makeNodePackage vs. makePythonPackage vs. makeHaskellPackage even though in many cases they share similar challenges (e.g., X and Y ecosystem's packages import dependencies from hardwired relative paths). It's a question of abstraction; makeXYZPackage exists, but there's no supra-ecosystem abstraction for writing it. That sounds like an obscure concern until you try using Nix as your daily driver for dev work. As long as you stick to one ecosystem, it's passable. Still a bad UX because nothing is properly documented and really bad anti-patterns (such as forcing package maintainers to update hundreds of thousands of packages to update a single package) are championed, but at least you only need to learn one ecosystem's quirks and idiosyncrasies. The situation changes very quickly as soon as you try to mesh NPM packages with Python with Ruby, etc. I actually raised this concern a while ago with the Nix devs, and their response was basically that it would take too much effort to harmonize all the different approaches. I thought that was a valid response, but it's unfortunate since I think it's the project's Achilles' heel.