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

Use a Nix Flake for m8c #160

Merged
merged 2 commits into from
Aug 8, 2024
Merged

Use a Nix Flake for m8c #160

merged 2 commits into from
Aug 8, 2024

Conversation

pope
Copy link
Contributor

@pope pope commented Jul 26, 2024

Flakes are a different way to specify a Nix project/configuration. It provides a few benefits over the existing solution:

  1. The exact versions of inputs are snapshot. This should mean that a build on one machine will use the exact same packages as the build on another.
  2. Flakes can be consumed by other Flakes. This would mean that folks could use this Flake as an import and then declaritively configure their m8c setup.
  3. While not used here now, this could make versioning easier. There wouldn't need to be a fetchFromGitHub step because someone could just use/run the app for that tagged branch. Ex: nix run github:laamaa/m8c?ref=v1.7.7

That said, this PR does rely on flake-compat to provide backward compatibility with default.nix and shell.nix. So a user could use nix-shell as before, or they could use nix develop (and potentially devenv in the future).

Flakes are a different way to specify a Nix project/configuration. It
provides a few benefits over the existing solution:

  1. The exact versions of inputs are snapshot. This should mean that a
     build on one machine will use the exact same packages as the build
     on another.
  2. Flakes can be consumed by other Flakes. This would mean that folks
     could use this Flake as an import and then declaritively configure
     their `m8c` setup.
  3. While not used here now, this could make versioning easier. There
     wouldn't need to be a `fetchFromGitHub` step because someone could
     just use/run the app for that tagged branch. Ex: `nix run
     github:laamaa/m8c?ref=v1.7.7`

That said, this PR does rely on flake-compat to provide backward
compatibility with `default.nix` and `shell.nix`. So a user could use
`nix-shell` as before, or they could use `nix develop` (and potentially
devenv in the future).
@pope
Copy link
Contributor Author

pope commented Jul 26, 2024

Hi. This was a shot in the dark to see if this is something you would be interested in leveraging in the Nix part of the codebase. If not, no hard feelings or anything like that.

I also didn't mention that one thing this flake does differently is that it installs treefmt. With it, you can run nix fmt or treefmt from install a shell and then the nix files will get formatted and checked for unused values. There's also a clang format option that can easily be turned on to quickly format all C files in the source too.

@laamaa
Copy link
Owner

laamaa commented Aug 2, 2024

Hi! Thanks for the PR. I personally haven't ever used Nix so I don't have much of an opinion on this... The current system is nice for (at least for me) in the way, that it updates the package definition file automatically on new releases and I'd hope to keep it so that there's no manual work required.

Maybe some other Nix users could comment on this too?

@pope
Copy link
Contributor Author

pope commented Aug 7, 2024

Good point about the self-updating package definition. I missed that it was done in a workflow and I added that change. That said, I am not totally sure how to test that flow. I don't want to add something that changes what you're used to - but adds some extra nix things for flake users.

@laamaa laamaa merged commit d731a8f into laamaa:main Aug 8, 2024
5 checks passed
@laamaa
Copy link
Owner

laamaa commented Aug 8, 2024

Thanks, looks good to me :)

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