-
-
Notifications
You must be signed in to change notification settings - Fork 284
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
Adding Nix building configuration #1222
base: main
Are you sure you want to change the base?
Conversation
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.
This dosn't build the binary correctly. It's supposed to be statically linked and to set the version when you run matchbox --version
. See Makefile for reference.
./result/bin/matchbox -version
was not built properly
How are you imaginging this being used? Just a helper for those who prefer to use nix-build for local iteration instead of the Makefile?
default.nix
Outdated
lib = pkgs.lib; | ||
matchbox = pkgs.buildGoModule { | ||
name = "matchbox"; | ||
src = lib.cleanSource ../matchbox; |
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.
can you explain cleanSource here?
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.
This is a recommended macro on development environments: https://gist.github.com/CMCDragonkai/8d91e90c47d810cffe7e65af15a6824c
This filters out some unwanted artifacts (temporary files, git data…).
matchbox = pkgs.buildGoModule { | ||
name = "matchbox"; | ||
src = lib.cleanSource ../matchbox; | ||
vendorHash = "sha256-sVC4xeQIcqAbKU4MOAtNicHcioYjdsleQwKWLstnjfk"; |
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.
How are you imaginging this being updated? I don't expect to maintain or bump a hash. If the aim is for this to be an alternative to using the Makefile during local iteration/development, vendorHash seems counter to quick iteration
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.
The vendor hash must be set per release tag because they are releases.
You can also set vendorHash
to null
in the main branch but nix-build
won’t work out of the box because go mod vendor
must be run first.
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.
For an in-project development Nix config, I think the config should just build from the local source. As in, if you edit some Go files or dependencies locally, running nix-build should just build it without someone having to fiddle with hashes. I'd prefer real releases and vendor pinning be done in upstream nixpkgs.
Do you see a usage story that aligns with this or no?
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.
Sounds fair.
Separately, I'm also aiming to get this packaged in nixpkgs, but I could possibly see value in having a local in-project build configuration if it matches the Makefile |
I saw it and asked the maintainer I know to have a look so it's merged. Now let's write the systemd service. |
This PR adds
default.nix
. This allows users to use the Nix building system to create the binary.matchbox
is then added to thenixstore
.