However I did not take the time to figure out github api rate limiting and pagination. postgres steampipe cli tool or foreign data wrapper can take some of the steps out of retrieving api results like this.
my query was just
SELECT
*
FROM
github_search_code
WHERE
query = 'filename:devenv.nix'
but could be expanded on with various rules, probably can filter on json responses about repo data like stars on repo etc etc haven’t tried it yet.
I submit that “popular” does not mean “good” or even “preferred”, and that in any case the aim of the Nix Team should not be product development for the masses but rather library development for use by other components of the ecosystem. Given the industry and this community’s problem with cargo-culting over understanding, this apparent popularity is instead an expected outcome from the proliferation of flakes-first Nix guides. I myself have followed many of these - including some produced by your team! - in the interest of getting things running quickly without needing to spelunk in the manuals, and until recently used a flake as the entrypoint to my own multi-platform configs. Flakes are a convenient UX over the Nix core features, and should be developed alongside - outside - the core. I broadly agree with Valentin on this point, though I would prefer the flake bits remain owned by the NixOS organization, to be developed not by the existing Nix Team but by a yet-to-be-created UX Team.
If flakes - which are not even functions - become the default unit of composition within the core Nix implementation, then we will have discarded a crowning achievement of computer science as a discipline, and as I have said elsewhere we should then return to the original thesis and consider a ground-up rework, with the knowledge gained from the past 18 years.
I genuinely mean this: if the Nix team thinks flakes should be removed, then they should choose that and go for it. This middle ground of not choosing is the biggest problem.
Personally, I think it is a mistake to remove them, but at this point – like I told Valentin a year ago, any choice is better than no choice.
Completely agree that a choice is better than no-choice. As a newcomer to nix/nixos it was confusing learning about how flakes are still experimental but almost every piece of info I’ve read nix recommended using them.
Of course, because Eelco, Graham, and their company detsys have been marketing them hard for years.
They are nevertheless terrible, not only did the problems I mentioned a year ago still exist:
As I’m not familiar about the pros/cons of flakes, I’m not gonna comment on that, but then there is this problem: as a newcomer I have to choose between a “terrible” implementation that has good documentation and a “good/proper” implementation that has abysmal documentation. Isn’t it obvious which will be chosen?
In my limited view of the situation this seems like a failure from the nix community to properly put out a documentation sane enough for anyone to be able to get things going fast.
What is this “good” implementation? I’d love to see it.
And you’ll have to ask the docs team about docs, they refuse to document flakes intentionally for reasons I don’t have insight into. But the community has documented flakes to death.
I wouldn’t say non-flakes are good either. And they are much better officially documented compared to flakes. Flakes do not have good documentation in any official sense, all the good info comes from blog posts and such.
Like I was getting at, both path-based and flake-based nix are not-great and I ended up leaving nix.
I consider blog posts and such documentation too, as I can refer to them when trying things out. Of course, something like the Archwiki would’ve been ideal, but in this regard, I struggled to find much good examples of path-based configs so I stuck with what I could easily refer to more: flakes.
If you don’t mind, what did you went with instead of nix?
For me flakes solve the pinning problem while keeping convenient UI, but the way it’s internally implemented is horrible.
Using flakes for anything other than NixOS configurations is really bad experience, the obvious example is trying to build something in a nixpkgs tree - the entire nixpkgs checkout is copied to the nix store every single time! Just why tf is it doing it, why it couldn’t do things the way regular nix-build does?
Again, at this point I’m hoping the Nix team makes a clear choice here. Say one way or another. The current status of a semi-vague to-do list and fellow members suggesting it be deleted is the worst scenario to be in.
I give you the authorization: carve out the Flakes implementation into your own plugin, which disables the --experimental flag for flakes, and work with the Nix team into adding the generic interfaces from which everyone will benefit into the plugin system.
Nothing will happen if you don’t make any move. Especially since, as you point it out, the Nix team is (at best) indecisive around the Flakes situation. They surely won’t take the time to migrate it into a plugin if (like you’re implying) they intend to remove it.
Now is the time to ensure this removal/migration happens smoothly for Flakes users. Now is the time to free the Nix team from the burden. Work with them, not against them.
This honestly doesn’t feel like an insane idea. I still after a year consider myself a nix newbie, I’ve used flakes in a few places where it seemed sensible, and also to work with other flakes, but even I have run up a few situations where they’re just added complexity or have missing features.
Moving as much of the flake handling as possible to a plugin, or a wrapper command, or something, feels like it might be the option that attracts the least amount of collective loathing. If a plugin is used, expand the interface (or create a new one) at will to allow this…?
I’m wondering if the Lix folks have thought about this - while I know they are focused on increment changes so far, they also seem to be the ones most prepared to consider longer term architectural changes…?
