Add nix package flake

[dakota-marshall]

This PR adds a functioning nix package flake that pulls from the specified release. This gives NixOS a way to install the latest release onto the system. I will also be pushing the non-flake version of this out to nixpkgs eventually, but figured id contribute the flake if you are interested in storing it in the repo itself.

[Kromtec]

Hi! Sounds cool, can you change PR to merge into develop? And is there a way that the version number (and hash?) does not have to be updated for every release?

[dakota-marshall]

I updated to develop. I can update the flake to not use hash checking with a simple lib.fakeSha256;, I think I have a workaround for the files being versioned in the release as well. Let me see if I can fix that, and I'll get it pushed up!

[donottellmetonottellyou]

Hi @dakota-marshall , I've been working on a nix package over here. If you wanted to provide feedback or just give it a thumbs up I'd appreciate it! It's a bit slow to add a new package, so anything helps.

If you built the package from source, BTW, you wouldn't have to update the hash since it would use the git commit of the flake directory instead. As it is, when you use the flake, the whole source is being copied into the nix store anyway, so you might as well build it. The advantage is that you would be able to get the latest version of the package on any branch the flake exists on instead of only pulling releases, at the cost of (on my slow machine) ~30 seconds of building.

My package already builds it from source, so if you want to use it as a reference for this flake I'd be fine with that.

[dakota-marshall]

Hi @dakota-marshall , I've been working on a nix package NixOS/nixpkgs#405918. If you wanted to provide feedback or just give it a thumbs up I'd appreciate it! It's a bit slow to add a new package, so anything helps.

Hey There! Nice work on the package. Im happy to give it a thumbs up, but im quite new to packaging for nix 😅 (this is my first real contribution to any project for it lol) so probably not much to give in the ways of advice

My package already builds it from source, so if you want to use it as a reference for this flake I'd be fine with that.

That would probably be the smarter option for sure, if youre fine with it ill probably take yours as reference and will try and spend some time tonight getting this over to build from source, thank you! Ironically I just got back into DF so im using this again and had to get it updated to the newest release so it was already fresh in my head lol

[dakota-marshall]

Alright, so I got this to a point where it does build from source, so that's a big plus! Few problems im not entirely sure how to fix:

@donottellmetonottellyou You might be the best to answer these:

• Is this deps.json file here strictly necessary? I assume this will change as the repo updates, any idea if I can generate this in any way
• I just have frontend still in its own dedicated file, im not sure if this is best practice or not? Should it be in a single file, if so im not knowledgeable enough to know what that would look like

And @Kromtec, for you:

• While you don't have to update the version and hash anymore with this new implementation, NuGet gets unhappy when I use a generic dev version for this. I have to give some sort of Semantic Versioning tag for the build. Currently I set it to 1.0.0-source, but I dont know if there is something better you would prefer it be set to. Is there something you use during your development?

I was going to try and see about finding the most recent tag from the repo and using that, but I didnt get too far down that rabbit whole as Id see if it was even an issue first lol

[donottellmetonottellyou]

Is this deps.json file here strictly necessary? I assume this will change as the repo updates, any idea if I can generate this in any way

This should only be a problem if Kromtec updates their dependencies, but is a problem worth looking at.

According to the reference, nugetDeps should be a path to a JSON file, a derivation, or a list of derivations. Given that it accepts a derivation, it should be possible to generate the deps and then build them inside the flake (I think). This would obviously make the build time longer, but not by too much I don't think. This outlines how to create the deps.json, so maybe it accepts a deps.json generated at build time? You'd just need to create a package that consists of a file output instead of a directory I think (cat deps.json > $out).

I don't think this would be an acceptable option for nixpkgs (I'm new too), but would work for a flake.

I just have frontend still in its own dedicated file, im not sure if this is best practice or not? Should it be in a single file, if so im not knowledgeable enough to know what that would look like

Well, for starters, the file already exists as a function {arguments}: {body}, so to call the function inside of the flake.nix you could start by adding the function and then calling it frontend = ({arguments}: {body}) {parameters};. Then you could remove all the parameters/arguments (replacing their usages in the body) and you are left with the function body, which would then be completely integrated into the file.

Otherwise, you could make the arguments available wherever you want to put the frontend in flake.nix, and just add the body directly.

Nix is confusing in that it uses curly braces for arguments, body, and calling functions lol. But nix uses a set instead of a list for arguments, so I'm not sure how else you would demonstrate that semantically.

EDIT: Make sure the npm shim for the backend doesn't conflict with the npm for the frontend, that's one reason they were in separate files.

While you don't have to update the version and hash anymore with this new implementation, NuGet gets unhappy when I use a generic dev version for this. I have to give some sort of Semantic Versioning tag for the build. Currently I set it to 1.0.0-source, but I dont know if there is something better you would prefer it be set to. Is there something you use during your development?

I was going to try and see about finding the most recent tag from the repo and using that, but I didnt get too far down that rabbit whole as Id see if it was even an issue first lol

You could use a variation on the nixpkgs versioning conventions, and just call the version 0-unstable. Technically the date of the commit is supposed to be after (0-unstable-1970-01-01), but I think it works regardless? The requirement is only that it starts with a digit for whatever reason.

I think the point is that it doesn't break semantic versioning because if semver started being used 0-unstable would be before 0.0.1 due to how the nixpkgs rfc works or whatever. Nix can't perfectly enforce semver because not all developers use it.