That's largely right. Getting semver version solving into Nix core itself is a goal of ours. FlakeHub implements it server-side because landing it in Nix without proving it out conceptually would be really hard, and also -- in my opinion -- reckless. Trying these things out in the world without committing the project to it long term is a good thing.
I think there is a perception that if problems like that are first solved in a proprietary service rather than in core tools, it may in extension tie the ecosystem to that service, while at the same time lessen the need to solve problems in the foundation. Even if this perception is wrong, I think it exists and why you see concerns raised in this thread.
These are indeed valid concerns, and I think that it’s fair for the community to be vigilant about such things and to ask probing questions. But my perspective is both:
- Nothing we’re doing is inherently proprietary or "secret sauce". FlakeHub isn’t doing anything magical, and the version solving feature would be better if Nix did it itself.
- Also, proprietary services can serve important functions in OSS communities. They can expand the user base significantly (like GitHub to Git) and they can send signals to maintainers of official tools about what’s a hit and what’s a dud. And I think that that’s precisely what we’re doing not just with FlakeHub but also with the Determinate Nix Installer, the Magic Nix Cache, the Flake Checker, and others.
reply