-
Notifications
You must be signed in to change notification settings - Fork 10
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
Add Nix Flake #27
Add Nix Flake #27
Conversation
Once the flake is in the repository, it will also allow running any arbitrary version / fork / etc. For example to run the flake from my fork and branch for this PR:
|
Not being a nix user myself, I am asking @andresilva as real nix user :) I see you "pushed" your |
There are ways to setup flakes with build options, but all the ones I was researching looked at pretty complicated and my Nix foo is actually not that strong. Yes I turned it on by default because my use case for this flake requires it and it follows the logic of my request in #26 where consumers should get all features by default when they are not provided with the tooling to change them and the expert users can build their own stripped down things when the need arises. In the case of Nix, the accommodation for speed is that all builds can be (and typically are) cached. This means that once you run this once or your local system it will be cached in your Nix store and the next time you run it it won't need to build+run, only run. The same is true in CI, it is basically crazy to try to run a Nix based workflow without caching as the entire dependency chain will take a long time to spin up, but with caching the difference between this project's binary with the feature enabled and not is pretty negligible. If somebody else wants to contribute the tooling to enable build time options in the Flake I'd be happy to use the results, but I don't have the bandwidth right now to figure it out. |
I should have enabled |
Ok, that sounds good to me. I will wait a bit to let @andresilva have a look but I don't mind merging this once you are happy with the content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. I personally never used naersk
and just try to use the rust build support from nixpkgs
as much as possible, but I don't see anything wrong with using it here.
I would be happy with that approach too, but could not figure out the right incantation. This PR is a squash of about 20 commits where I was trying to get anything to work. This was by far the cleanest working thing I came up with. I'm sure it could be done differently, but I urgently needed something that worked and this actually seemed pretty robust. I ended up doing almost line for line the same thing on a couple other projects and it held up well even to the underlying project getting a refactor and major release. |
Hi, I just wanted to let you know that See https://search.nixos.org/packages?channel=unstable&show=tera-cli&from=0&size=50&sort=relevance&type=packages&query=tera-cli and https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/te/tera-cli/package.nix |
❤️ thank you for the update. |
This will enable the GitHub repository to be executed directly as a Nix command, quite useful for CI runners and projects using Nix as a build environment.