I agree with @Infinisil's assessment[1]. This seems to summuarize my Nix experience in the last two years. So many products "fixing Nix" with little to no effort to upstream any of it. As a Nix consumer, it's frustrating because every one of these projects I chose to adopt is basically playing a huge game of risk. I've already had at least a couple of them deprecated/abandoned on me.
Not saying it's a totally unique experience to Nix. It just seems especially concentrated at the moment.
Yeah it's less than ideal however FWIW graham's comments [1] seem to indicate that this project stemmed out of fairly rapid development over the course of a weekend with some additional time taken to polish it up.
If that's the case they may see this as some easy duct tape over top of flakes that could take the pain off of flakes itself while flakes actually work through the process of stabilizing.
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.
I really want to think the best of DetSys, and I use some of their work and love it. Some people who work at DetSys have been prolific contributors in the Nix community as long as I can remember. I also understand the urge (and precedent, within the Nix community) to go off and build your own thing to experiment.
But I think with the general pain and anxiety many longstanding community members are feeling over increasing commercial investment in Nix as well as the whole design and rollout of flakes, more upstream-first development would go a long way (as would quickly making good on statements of interest to upstream these features).
I know folks have anxieties about commercial investment, and anxieties about developing flakes. Whenever we hit bugs in flakes, we go work upstream to fix them. We do this rather often :).
I won't try to persuade you one way or another on commercial investment other than it is here with or without DetSys, and we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core. We don't _want_ to be solving the version on the server, but I'm rather sure it would have taken months if not years to get an experiment merged. And for good reason: we all want to make sure what goes in to Nix is solid.
> I also think developing features and improvements to Nix outside of it is a good way to prove out ideas that can be eventually merged in to core.
I think it definitely can be. Naturally, more DetSys code and ideas that go through that whole journey, the more likely Nixers will be to reflexively trust the company when it comes to new projects. I'm optimistic that that can turn out well.
> we've released a rather large suite of tools to make using Nix more pleasant and all but one (flakehub's backend) is free and open source. I feel that is a good way to go!
I think open-core and proprietary services based on F/OSS can be an effective business model that helps get valuable open-source work done.
For me, Red Hat's model and Qt-style dual licensing are even more attractive because they are based on comprehensive F/OSS licensing.
That said, companies have to figure out licensing strategies that make sense for them and the particular markets and software they're dealing with. I don't begrudge, e.g., Determinate Systems or Cachix or Hercules taking up strategies that involve proprietary services because I've seen people involved with all three companies continue to make important contributions to Nix, Nixpkgs, and F/OSS tooling in the ecosystem that's about more than just plugging into those services. That signals good faith engagement to me.
But seeing stuff like version management get handled in bespoke ways in proprietary services like FlakeHub or at Flox when it remains unaddressed in Nix itself naturally raises an alarm, though.
> We don't _want_ to be solving the version on the server,
I feel like that's good sense architecturally.
Seeing this problem solved in Nix itself will help establish a record and reputation.
I will try to put myself as an outsider and just reflect on what I see. We have a very innovative Linux distribution / packaging etc software, where there is no dominant commercial actor. Instead there are a number of smaller companies specializing in evolving the ecosystem, selling services around it and so on. There is opportunity in Nix future for a commercial actor to make a lot of money by becoming the most trusted authority in aspects of it. Becoming the next Red Hat or something like that. I sense there is a lot of positioning and hustling to become THE Nix company that takes pole position and becomes the dominant one.
Once in a while, there have been an announcement like this, which has not been well received. I am a little worried about it, and what it can lead to for the future. I worry it can split the community and be harmful to the future of very innovative software. I am trying to think of a similar situation within another area of the Linux or Open Source space, but can't really come up with good examples.
Interested to hear if these thoughts are well founded or just a bad take.
We strongly value open source software through and through, and have a team of long term contributors to open-source projects and communities. Part of open source is being allowed to build and experiment and see what happens. I find it unfortunate that people respond so strongly to our work, but I think part of it is a bit of fear of the unknown. We’ve published a lot of tools that we think are really nice, and almost all of them are totally open source and free (though the flakehub.com backend currently is not). Hopefully in the end the proof is in the pudding.
It seems like the Nix community is already headed towards a soft fork. DetSys already provides their own Nix installer, and now FlakeHub. Jetpack has Devbox, which is an entirely different interface over flakes.
I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. (Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks.) Frankly I’m glad that people are working to make it more user friendly. It reminds me a lot of when I first tried Stack for Haskell: packages just worked out of the box, no more tracking down arcane cabal-install errors and figuring out why it didn’t build in my machine.
That installer has actually been developed with community collaboration from outside DetSys from early on in its lifecycle via the Nix Installer Working Group¹, which includes stakeholders from other companies and whoever else volunteered to get involved.
I haven't followed it super closely recently, but to the best of my knowledge DetSys has done a good job with that project of orienting themselves towards the wider community and upstreaming that work.
FWIW, the maintainer of and chief contributor to that project is also extremely responsive to community activity on GitHub as well. I reported a few bugs the other day and was frankly delighted by how it went. It's being developed in the open, like proper open-source. The Determinate Nix Installer is not at all a 'let's do this in-house, behind closed doors, then throw it over the fence' kind of effort.
Point of clarification: we are fully open to upstreaming the installer in whole or in part and have been from the get-go.[^1] But the installer is a pretty radical departure from the current official installer. The official installer is written in Bash; the DetSys installer is written in Rust. The official installer targets fairly "standard" platforms; the DetSys installer has experimental support for things like the SteamDeck. And so on.
We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
The default installer doesn't even support uninstalling Nix, which was a real pain when I tried to do so.
> We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't.
I hope nothing I said suggested I didn't think this was ok. I really appreciate that the DetSys installer exists. I'm just not sure why anyone would use the default installer given that it does.
> I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently.
Nix has a higher difficulty curve, and rougher corners, than most tools out there.
The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?".
Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything.
> Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks
I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do.
But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.
> Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do.
Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility.
Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal.
edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software. https://www.nixhub.io/packages/erlang
Note that this approach isn't without its downsides (compared to overriding the version in nixpkgs, or using a separate nix package). -- Mainly, since it uses an older nixpkgs version, the dependencies will also be that old version. (They won't have any security fixes which have been released since then; and it'll take up more disk space to install).
> Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version.
Supporting multiple versions be more helpful at the cost of more effort to maintain. It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
> I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software
Correct.
> It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
> In what universe is it reasonable to make package consumers write software...
Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`).
I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile.
With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is.
In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs.
> Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder.
Yeah, Nix is much more difficult to use than other tools.
Nix's UX is one where you pay a big cost upfront in order to save on effort later.
e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.
Every piece of technology is incapable of doing anything if you label all solutions as "hacks."
Here's proof:
Is it possible to write C programs that manipulate strings? No, because string library functions are "hacks." Is it possible to write a bash script that passes arguments with spaces to a command? No, because quoting and character escaping are "hacks."
Nix packages are malleable. With a bit of code, customizations can be applied to individual packages and entire dependency closures alike. An overlay is an embodiment of this property. It allows the user to create packages that fits their unique needs on the fly without having to repackage the whole world. No other package manager maybe besides Guix has this capability. I don't think it's fair to dismiss it as an "hack."
Not saying it's a totally unique experience to Nix. It just seems especially concentrated at the moment.
[1]: https://discourse.nixos.org/t/introducing-flakehub/32044/3?u...