Redesign in light of lixPackageSets in nixpkgs #61
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Since Lix in nixpkgs has grown a nix-eval-jobs package, we can do the nix-eval-jobs overrides. https://github.com/NixOS/nixpkgs/pull/391402
But also, this really starts making the lix-module a HEAD thing. It probably should inject the lix into
lixPackageSets.nightlyor something like that and then set pkgs.nix and pkgs.lix and pkgs.nix-eval-jobs to point into that.Going to be a bit subtle to make it work.
This should probably disappear completely, tbh.
We can have HEAD in nixpkgs directly, @alois31 has been dealing with this. We should refocus efforts on better updating frequency in nixpkgs and deprecate this whole module.
Plan:
We cannot entirely sunset the module but we can delete most of it because of the simplification of nixpkgs. It's not acceptable imo that we won't have a way to run HEAD directly from our own packaging that is slightly different and better for development.
To be clear: the fact that the proposed idea ties the build of lix you're running to your version of nixpkgs will increase our QA feedback from often under 24h to a week or more, and this will be the case in any world where we change the published procedure for running HEAD to not use the lix module.
Also, you still need to handle use cases like system profile on non NixOS because what we have here is vastly nicer than nix upgrade-nix.
To remove the high quality parts of this packaging that fundamentally need building from source is to set back our QA story to be the same as the QA story of CppNix.
That being said: this module causes toil. Chiefly on release branches. Those suck and we can get rid of those.
@jade wrote in #61 (comment):
Hm, that's fair, honestly. But your argument applies equally and rightfully to release branches as well.
I just feel like this is a maintenance budget problem and a lack of automation.
If we can make the releng action for nixos-module almost fully automatic, that'd be pretty good.
My biggest problem right now is that too many people are using this module and in practice, nixpkgs fixed
__structuredAttrs = true;on day 1, and we were unable to do it in due time (not a blame to you, Jade, you know how I work and I fully understand how hard is it for you and I appreciate your efforts). So I'd like to push most users to the community maintained Nixpkgs so that we can relax deadlines on this module.In the end, this intent ends up converging towards a HEAD-only solution again.
yes. equally i think that if we remove all the unnecessary parts of this module and port it to the new nixpkgs infra it should become less fragile and we can implement a deprecation of the .default attribute to become .lixFromNixpkgs and ideally then wipe out all the version specific bits altogether so it uses so little api it basically can't break. or we eliminate it completely for release branches. either way.
@raito wrote in #61 (comment):
Why not include the NixOS module directly in the Lix repo?
having to do an entire releng cycle for the module sounds like hell but if we don't support backports it is more plausible
OK, here's the action plan I am willing to implement under a short timeline (I need validation because I have too much on my plate):
lixFromNixpkgsand offerlixFromLixas an alternative nowconfig.nixImplementation = "lix";or something and add a deprecation warning to all release branches.This would be phase 1 and keep
nixos-modulefor HEAD intact. Happy to take any feedback / adjustments on this action plan.@jade does it work for you?
I think the default for HEAD needs to remain a full source build as we cannot tolerate the latency of getting builds into nixpkgs before we find issues with them. Other than that minor quibble I agree entirely. We really want to just get all the complexity gone on release branches via work in nixpkgs itself and I think it's arguable that we don't even have to ship source builds on those at all.
I did write "keep
nixos-modulefor HEAD intact", so I don't think there's any minor quibble at all, right?Thanks to @delroth heroic assistance and patience, first 2 items are good. 3rd item is probably a trivial thing to do, I need to look in Renovate configuration.
I will submit the default overlay patch for the various release branches in the next days.
@raito wrote in #61 (comment):
Maybe it's a misunderstanding, but
lixFromNixpkgsfor HEAD would mean lixPackageSets.git, which must not be the default for HEAD testing specifically, for the mentioned reasons of "it's a lix HEAD known to not have totally blatant errors in it but delayed by like a week", as being delayed by a week is not acceptable. But we should support it optionally.On release branches the default should be lixFromNixpkgs for sure.
lixFromNixpkgsshould not be used for HEAD if this can dispel any confusion, so we are in agreement I believe.#78 implements the validation CI. I intend to only test for "it-builds" for now, more things can be tested as we go, but we mostly need to blanket verify that things didn't die brutally IMHO (eval + build of Lix).
Improvement of that can happen as we go further.
At this point, I only need to fix Renovate configuration, merge the CI configuration and go for "Make the default overlay lixFromNixpkgs and offer lixFromLix as an alternative now" in release branches only.
The next steps I presented of phase 1 will not be started this week, neither next week I foresee.
All that remains is switching up to
lixFromNixpkgson release branches and start merging automatic lockfile maintenance.We should nuke 2.90 tbh.
2.92 & 2.93 has been taken care of.
2.91 is still being fixed due to entrypoint annoyances.
We can just ignore 2.90.0 for lockfile maintenance, perhaps, it's good to add a special message for "this is not supported anymore" and bump it.
A new todolist item is to update the website on these matters. I will do it when I can.
2.91 is now done.
lix-project/lix-website#58 up.