Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init: nix support #1131

Merged
merged 8 commits into from
Feb 27, 2022
Merged

init: nix support #1131

merged 8 commits into from
Feb 27, 2022

Conversation

a-kenji
Copy link
Contributor

@a-kenji a-kenji commented Feb 26, 2022

No description provided.

@a-kenji
Copy link
Contributor Author

a-kenji commented Feb 26, 2022

Hey @colemickens as promised here already a draft of initial nix support. I would be happy if you would look over it.

@a-kenji a-kenji changed the title Init nix support init: nix support Feb 26, 2022
@colemickens
Copy link

Looks good to me, but two thoughts:

  • (nit, not blocker): I'm personally of the opinion that the ecosystem can do better than needing flake-utils, as I just opened here: add more builtins (and possilby backport) so that flake-utils can be more optional NixOS/nix#6172.
  • (maybe blocker? or another quick PR?) helix and jj both added GitHub workflows to keep their flake inputs up to date as well (I can't remember off the top of my head if they also push the built nix artifacts to a cache. That's also very easy to add down the line with cachix.org etc)

@a-kenji
Copy link
Contributor Author

a-kenji commented Feb 27, 2022

Thank you!

(nit, not blocker): I'm personally of the opinion that the ecosystem can do better than needing flake-utils

It would be awesome, if something like that would be more straight forward in nix!

(maybe blocker? or another quick PR?) helix and jj both added GitHub workflows to keep their flake inputs up to date as well (I can't remember off the top of my head if they also push the built nix artifacts to a cache. That's also very easy to add down the line with cachix.org etc)

I agree it is kind of a blocker, I want to address it in a different pr.
I am kind of torn on the implementation still. I want to add simple checks to the ci for the nix build, but I also don't want to make it too intrusive for people that don't care about the builds.

I am thinking about updating the inputs automatically on a weekly basis, what do you think about that?

Kind of like I do on https://github.com/a-kenji/zellij-nix, there I update all the inputs on a weekly basis and I advance the zellij input nightly.

I just looked at jj and helix and I can't see any automated updates there. Maybe I am looking at the wrong place there?

@a-kenji
Copy link
Contributor Author

a-kenji commented Feb 27, 2022

Also what do you think of splitting the files up, like I did in
https://github.com/a-kenji/zellij-nix/blob/main/nix/default.nix,
is that generally a bad idea?

@a-kenji a-kenji merged commit 49396fa into zellij-org:main Feb 27, 2022
a-kenji added a commit to a-kenji/zellij that referenced this pull request Feb 27, 2022
as discussed in zellij-org#1131

Add a github action that creating a weekly pr with updated
flake inputs.
a-kenji added a commit that referenced this pull request Feb 27, 2022
as discussed in #1131

Add a github action that creating a weekly pr with updated
flake inputs.
@colemickens
Copy link

🎊 ! And yes, I'm sorry, my comment was inaccurate - I totally missed that they added a build check without updating inputs. I'll have to make a note to loop back around on that.

Personally, the faster the better -- nixpkgs-wayland updates every 30-60 minutes or something like that -- all package sources and nix inputs are pulled up.

For now, it's not a huge issue, users can override nixpkgs on importing these repos to build latest, but I do want to circle back around and adding updates, and then maybe in nix-community have a centralized job that:

  1. builds zellij/helix/jj flakes as-they-are
  2. builds them with their nixpkgs updated to latest nixos-unstable

That way we can provide cache hits for as many folks as possible, and also try to help catch build-breaks early, etc. Just a idea.

@a-kenji a-kenji deleted the init-nix-support branch March 5, 2022 12:28
a-kenji added a commit to a-kenji/zellij that referenced this pull request Mar 13, 2022
as discussed in zellij-org#1131

Add a github action that creating a weekly pr with updated
flake inputs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants