Reworked nix infrastructure

[Rexcrazy804]

• overhauled the flake.nix improving and cleaning up the mess that was left behind after Nix support 2.0 #194
• correctly address [Bug] Nix build isn't working #164 (see todo)
• returned nixosModule that Nix support 2.0 #194 deleted (I question why it was merged in the first place)
• modularized flake into nix/package.nix and nix/module.nix
• updated package metadata
• made package versioning independent
• fix the workflow that populates an invalid hash.

This branch is currently in a working state and I welcome nixos users to test this.

[Rexcrazy804]

The module can be installed fairly easily with the following steps:

Add the forked branch to inputs

{
    inputs.winboat = {
      url = "github:Rexcrazy804/winboat?ref=fix-nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
}

import the module and enable it

{inputs, ... }: {
  imports = [
    inputs.winboat.nixosModules.default
  ];
  users.users.YourUsername.extraGroups = ["docker"];
  services.winboat.enable = true;
}

[NIKOSTERs]

I can confirm that it works on latest stable NixOS

[0xDracula]

I can confirm that it works on latest unstable NixOS.

[Simon-Weij]

Can I ask why you didn't just re-add the nixosModules? You're currently working on issues that Nix Support 2.0 already resolved. (Nix support 2.0 was added in 0.8.5 iirc, the issues you mentioned were made for versions before that)

[Levev]

Thank you for taking your time to iron out our nix infrastructure!
Thing is, neither me nor @TibixDev know much about nix's packaging system, so forgive us for #194's pitfalls.
We've gotten another PR(#277) which addresses the flake hash issue as well, while also fixing #177. Since these PR's are in conflict, I can't quite go ahead and merge, since as I understand this PR doesn't tackle the workflow issue yet(?).

Thanks again for your work, please keep us updated on when and how we should go about the merge!

[Rexcrazy804]

Can I ask why you didn't just re-add the nixosModules?

The state of the derivations were terrible, I had to fix those first.

You're currently working on issues that Nix Support 2.0 already resolved

I've done more than just that.

[Rexcrazy804]

We've gotten another PR(#277) which addresses the flake hash issue as well, while also fixing #177.

I'd say one course of action is to have the pr reworked based on these changes as this pr has overhauled the old structure entirely.

The second thing I can think of is having a derrivaiton that builds directly from source, which is the most commong approach flakes that reside in repos use, which removes any and all need for any workflow, the derrivaiton is simply built from the master branch and hence is updated alongside the master branch and wouldn't require a workflow to update the hash of the source. Eliminating a need for updating the derrivaiton with each release (however we could add a workflow that checks if the nix drv builds on each release)

since as I understand this PR doesn't tackle the workflow issue yet

It does, which is why I have marked it as complete on the todo list

[Rexcrazy804]

to summarize we have two options to move this forward

1. switch to a derrivation that builds from source eliminating the need for a hash updating workflow each release
2. merge this and rework fix: update release tags with corrected flake hash #277

In my opinion 1. is ideal, and is the standard for derrivaitons that live on the source repo. I can instantly get that going since I've already written a derrivation that can build this from source in nix. The largest pitfall of the orignal derrivations used in this repo was NOT building the package from source, this is understandable since the contributers probably were new to writing derrivations in the first place. This is clearly true for pr #194 which featured ai assisted, severely under polished code.

[Levev]

Sure, getting rid of the has updating workflow could be nice, but as of right now, the main branch isn't stable; release tags are. Do you think that's a problem?

Also, there's some great work over at NixOS/nixpkgs#451068 😃

[Rexcrazy804]

Do you think that's a problem?

Not necessarily, since with nix (more specifically nix flakes and npins/niv) dependencies are pinned so it easy for users to track and use specific revisions as well as reverting to older revisioms / tags.

Also, there's some great work over at NixOS/nixpkgs#451068

Mhm that's the source building approach I've mentioned. In nixpkgs it is standard to build from source if the source is available. Once that is merged, users seeking stability can stick with nixpkgs' winboat package, and others wishing to be on the bleeding edge can use the flake in this repo to always have lastest changes