So I get that this is the nix bashing thread, but c’mon. Those strike me as minor polish issues - which should really be expected given how young the project is - sprinkled with misunderstandings about nix and flakes.
There are much bigger problems with the concept of integrating with npm, api concerns, etc.
Not meant to be taken personally, but slight rant incoming…
I can imagine a bit of processing overhead, even if download speed reduction seems odd.
Of course it would be cool to see some actual comparable performance comparisons, and do some deep dive benchmarking. But this project is very young, the API hasn’t even settled yet, and your first complaint is that it’s slower than the specifically optimized original? For cached inputs you should only download once no less?
And even then, maybe you’re conflating the speed of downloading nodejs and all its deps on top of the packages? Maybe even using unstable for a flake input on an otherwise stable/outdated system so you’re downloading all of glibc and up as well? Or maybe you’re unwittingly comparing to a well-primed npm cache?
Yes, we can say all three of the above are UX problems. But they’re ultimately just unfair comparisons caused by misunderstandings.
You’re sure this isn’t some slow terminal getting stuck with escape sequences? Maybe something like an untweaked emacs, vi or vscode shell that doesn’t know how to handle ansi escape sequences, because somehow that’s still hard in 2023?
It seems like odd criticism of dream2nix, though, given it doesn’t control the output. Hell, I don’t think it’s even fair criticism of nix, shells and terminal emulators should do a better job at not breaking themselves. IME this is often caused by broken PS1s anyway.
Yes that’s slightly unusual, but it’s a nix feature, not a dream2nix decision. I think the reasoning for the feature was that it actively speeds up builds, because most terminals can’t keep up with truly large builds, and there’s nothing worse than making your CPUs spin idle because you’re printing enough text to keep an avid reader occupied for 10 lifetimes.
Stick -L after the command for verbose logging. It’s shown in the help output and the manual under “logging-related options”, though I appreciate nobody ever rtfm.
Maybe there could be a feature request to give this hint on the output as well where it currently instructs you to use nix log?
At least I got some constructive idea out of this rant.
Personally, my main problem with using it for npm was that the build script used for it did some utterly insane reshuffling of directories until recently, which completely broke some build tools. It was something like building in $out and a nested node_modules dir. But that was fixed.
Other problems I’ve run into is the usual unreproducibility of npm projects that like downloading random precompiled binaries as if that isn’t a huge problem.
Running something like the npm elm repos via dream2nix just isn’t going to work ootb either.
dream2nix has pretty good handling of overrides to fix problems like these though, which I like a lot.
I’ve also had surprisingly good experiences with the devshells, personally, it handles complex things like typescript language server envs out of the box for me. Not really for rust, but that’s more of a side effect of the silly situation with rust-analyzer.
I think it ended up being quite concise and pretty for my personal website. And that’s while using parcel, which I didn’t really expect to work at all, given the nested build toolingness.
I think dream2nix is impressive for having gotten as far as it has. There are very few projects that actually attempt to bridge the gaps between all these modern build/packaging tools, and so far dream2nix is doing a great job.
I was quite disappointed, as dream2nix looked like a very neat tool.