5 ms·
> Or are you mainly worried that the kind of natural vendorization that Nix provides will lead developers to only test their software on narrower and narrower r
by firstlink 3y ago
> Or are you mainly worried that the kind of natural vendorization that Nix provides will lead developers to only test their software on narrower and narrower ranges of version combinations?
I guess, but I would not characterize it as a problem of testing. As I understand it the thing you are "supposed" to do is use the upstream developer's exact dependency tree, unless you override it in which case you've completely voided the warranty as it were. Or, this applies to collaborators across the same project too. This means using whatever broken outdated environment that developer happens to prefer, possibly because of other software on their system transitively requiring ridiculous environments, or because they're just lazy or whatever.
This doesn't apply to software in the blessed set that's kept up to date, but I don't think you get points for being at parity with, say, Ubuntu.
- pxc 3y agoAs someone who sometimes uses Nix to put together devShells for small projects at work, I admit there are times I might be inclined to point someone to the flake as a workaround for a versioning issue. But I would still consider it a bug in my app to be broken with a newer version of a library than what I have pinned. I believe many developers must feel similarly! At the end of the day, when it comes to development environments, Nix should be a way to help provide a reproducible fast track for building and/or running the software, not a preemptive dismissal of all other possible downstream users and distros! If your software has a Nix flake but no build instructions, it's missing documentation. That's probably okay for solo open-source projects that are small and indifferent to building a userbase, but I hope maintainers and companies will readily recognize that as they grow they'll have to fill that gap at some point.