This is one of my first attempts of packaging something for nix, so I have a feeling this could be way better. I also would like to know, how would I add this package to nixpkgs or make it so I can add flatpak-compose to my flake
Youâre packaging the binary, the better way would would be to build it from source.
Since it is written in Go that should be fairly easy to do.
You can look at the Go section in the Nixpkgs manual and search in the Nixpkgs repository for examples.
This is a Go application I packaged, it might not be the best example however as it is only the second package I added and I have never written a line of Go:
This could be a possibility too, although I always have wondered if a rebuild my system will it build this package again or will it only do the latter if the version has been changed?
It will behave like any other Nix package.
Unless you donât change the related Nix code or the source it wonât have to rebuild it.
If you garbage collect it then you will have to rebuild it again, however this wonât happen if it is part of your NixOS configuration.
If you add it to the Nixpkgs repository you get the nice benefit that it gets built for you and the update bot takes care of tracking the updates.
I will do this in the future thanks for clearing so much up! Before I mark your answer as solution (thanks again) I am wondering if my nix file could be improved since its generated by nix-init
If youâre contributing this to nixpkgs, thereâs nothing objective to improve here other than maybe using refs/tags/${version} (although I believe another arg was added to fetchFromGitHub which avoids that boilerplate, even), and of course the meta.maintainers should be set to yourself and/or someone else willing.
The rec keyword allows recursive attribute sets, meaning attributes can reference each other within the same set. While this is convenient, it can lead to problems:
Implicit dependencies: When using rec, dependencies between attributes makes the code less clear and can introduce infinite recursion.
Performance overhead: Recursive attribute sets require additional computation to resolve interdependent references via fixpoint iteration.
The with keyword brings all attributes from an attribute set into the current scope:
Name collisions: Introduces risk of unintentional name shadowing and conflicts
Reduces code readability: Makes it unclear where specific attributes are coming from
No static analysis: The ambiguity caused by with makes static analysis very difficult
Here, inherit pname; is just syntax sugar for pname = pname; which is allowed when you donât use rec (since otherwise thatâs an infinite recursion right there).
It is more explicit which makes it easier to see whatâs going on which I like.
But as I said Iâm no expert and I probably prefer certain crutches to help me understand code which others would not use anymore.
I built it as test, and the resulting bin file is named âcmdâ, is this a issue? The file name should just be flatpak-compose; do I add a mv command to extraInstallCommands or something
In their GitHub action faan11 use the -o option when building the package.
Maybe you can use it somehow with buildGoModule as well or maybe the name should be already present in the source.
For this I donât know enough about Go.