o_O isn’t this how things already work? The RFC says:
The lock file contains a graph structure isomorphic to the graph of dependencies of the root flake.
and I assumed that’s how it works, that only root lock matters, and that it is transitive. Is it not the case?
I think only the root flake lock matters, in terms of pinned revisions, but the named inputs can be changed via follows to point to different sources (ie, branches, typically)
It’s interesting that it doesn’t necessary needs to be a part of the nix tool. A model with “server side” resolver, where the cli only knows about URLs, lockfiles, and redirects that go into the lockfile, and the actual semantics of version resolution is encoded into a server serving a particular URL could be a viable long-term solution.
A prior art here would be Deno, which works much the same way:
$ exa -l
.rw-r--r-- 3 matklad 23 Aug 08:44 deno.json
.rw-r--r-- 63 matklad 23 Aug 08:45 main.ts
$ cat main.ts
import * as colors from "https://deno.land/std/fmt/colors.ts";
$ deno run main.ts
Warning Implicitly using latest version (0.199.0) for https://deno.land/std/fmt/colors.ts
$ cat deno.lock
{
"version": "2",
"remote": {
"https://deno.land/std@0.199.0/fmt/colors.ts": "a7eecffdf3d1d54db890723b303847b6e0a1ab4b528ba6958b8f2e754cf1b3bc"
}
}
(no judgment on which model is actually better, but both are viable)
I also want to point out that this is PR speak and gaslighting, by which I mean telling people their problems are a part of the solutions and how they’ve solved so many of them.
This is a typical apology on everyone else’s behalf; they’re not sorry for what they did, they’re sorry that someone doesn’t like it. It also serves as gaslighted wording that you’re supposed to be excited about this.
This does not address existing concerns at all. Least of all the ones alluded to by the comment @grahamc is replying to.
This is white-knighting, another form of gaslighting, suggesting DetSys must be heroes despite as-of-yet unanswered criticisms.
This is PR speak for “we don’t care that it isn’t going the way we want; we’re doing what we want anyway.”
From a journalistic perspective, I cannot take DetSys’s claims seriously yet. They clearly want to further their own designs, which may well be good ones. But the tactics used here leave a bad taste in my mouth
Have the authors of the flakes currently added to flakehub in any way accepted to be indexed? This will drive more traffic to their flake and increase the maintenance burden. related
I agree with others that pushing for stabilization of flakes and fixing issues that currently exist around them should be prioritized.
This effort, although it might be nice, is like building a castle on sand to me - as long as flakes are not stable and officially the way to go (in my perception it is not), I see no point in building something like flakehub.
Also, as others have notes, this might create more problems (around trust for example) than it solves. Also: A centralized infrastructure for a distributed tool? GitHub is also a centralized infrastructure for a distributed tool and we see all the problems with it… Thus I can only say that I don’t like what’s happening here.
Your workforce - IMHO - would have been needed elsewhere much more dearly!
I think the contentious reception here is more of a function of Determinate System’s general reputation with the Nix community (or at least its segment here) than of the merits of FlakeHub itself.
@grahamc is correct that a comment on RFC 0144 suggested doing this as an external project before doing it as an RFC:
However, since this looks like it could be easily implemented outside of Nix, I’d strongly suggest doing so first so that everyone can judge the usefulness.
So I don’t think it’s fair to turn around and blame DS for not doing this work upstream. (Elsewhere, he said upstreaming it was an eventual goal.) Similarly, while I personally wish more effort were being put into stabilizing flakes before building even more on top of them, grahamc did say that this was a weekend project:
In the meantime, the proof of concept of FlakeHub took about a weekend to put together.
So it seems unfair to dunk on FlakeHub for representing effort not put into some other aspect of Nix or flakes. Let him who has not spent his last weekend stabilizing flakes throw the first stone, or something.
Like many long-running marital spats: it’s not that the dishes were left out, it’s what the dishes being left out represents; it’s not the proximate issue being litigated, it’s every previous unresolved issue being re-litigated with the current issue as a proxy. It’s not that FlakeHub has technical issues outside of what one would expect from a weekend project, it’s that FlakeHub (and the manner in which it was developed and announced) is another instance of a pattern of behavior from DS, and it’s that longer pattern that people are reacting to.
I’m not a marriage counselor or experienced community moderator, so I don’t have any real solutions to offer. Maybe DS should work with Nix leadership to host or sponsor a flake hackathon to implement all the unimplemented RFCs? Maybe make a blog post about which in-progress RFCs you’re shepherding? We’re not going to get along better by having this same fight all over again, that’s for sure.
It’s just tiresome.
@Jaculabilis that hackathon with the rfcs and a reward from a sponsor is a great idea, there are many bigger technologies that have done this and it mostly leads to great success!
Is there a plan to release FlakeHub source code in the future?
Having flakes for reproducible and automated builds is good, but if the workflow depends on an proprietary upstream service, this is really concerning.
I’d like to point out that if the Flakes project had been started by most other persons, it would have been a community/third party project instead of something part of code Nix. There would be no “upstream” in the way we are talking about here. And as @Ericson2314 already pointed out, we’d be probably better off that way as a whole. (Of course it is too late now, Flakes have picked up too much momentum too fundamentally change course)
A lot of peoples’ frustration with Flakes comes from the fact that they have been developed in a way which would be more appropriate for an external project to Nix than something weaved into its core functionality. This impedance mismatch has proven difficult to resolve and is an ongoing cause for tension, as clearly visible in this thread.
I can totally understand why people would like to see these issues resolved in upstream Nix instead. But I’d argue that moving some of that development out into external projects first, small experiments which can iterate at a faster pace, may actually be a good thing.
It seems like the source code to flake hub has not been released though. I didn’t see any mention of the intention to do so either, but I might have missed it.
There is certain core capability that had to be in nix itself, and some in nixpkgs to make it a viable experiment, and there is the experimental features flag / marker around it to address the concerns (about dependencies and assumptions sneaking in to the rest of nixpkgs, for example). There’s probably room for some quiet armchair analysis about exactly where the boundary lies or how to improve the pattern/process in future, but we are now clearly at the point where enough is in place to usefully enable such external experiments.
I’m really tired of arguments and implications about people’s intent, especially when it seems like any choice is wrong in someone’s eyes. That’s not a comment about this post in particular, by the way. However, if we keep on like this in general, no experiments can succeed and no material progress will be made.
I can easily imagine a future where FlakeHub’s source is public. However, we don’t have any specific plans or timelines there.
What is your reasoning for not having it public, right now?
At least the CLI tool is open source. Does it also work independently from FlakeHub?
fh is a CLI for FlakeHub, just as, say, gh is a CLI for GitHub. So no, it doesn’t really work independently from FlakeHub, although some of its functionality, like fh init is more broadly useful.