Overhaul nix flake

[ozwaldorf]

Flake overhaul

I'm still new to nix, so if I made any incorrect assumptions just let me know!

• Updated flake.lock
• Allow using both the override and insert overlay strategies, keep the previous default (override)
• Cleanup extra devshell packages (duplicates already included by inputsFrom)
• Remove flake-compat input (hasnt been fully setup afaik)
• Revert libinput patch filter
• Define a nix fmt utility for the flake, I went with the newly released nixpkgs-rfc-style

Explanation

Trying to use the current flake overlay with a nixos flake on a recent unstable revision wreaks some havoc, due to the newer nixpkgs.sway-unwrapped using wlroots 0.17. The way the overlay is currently implemented, the package can break due to it just being an override of whatever parent nixpkgs is passed in. An alternative way would be to define the package output directly using the locked nixpkgs, and the overlay can just insert the locked working version into the users nixpkgs. We can offer both strategies, for whichever users need more. This pattern also seems to be provided by the popular flake-parts nix library, under their "overlay for free", so I assume it's a popular flow.

Flake-compat input should be removed since the repository doesn't have a default.nix to expose it, and nobody could use this repo as a non flake anyway (AFAIK)

Updated nixpkgs no longer uses the libinput patch, so it should be safe to remove.

Example usage of the new insert overlay

Use the overlay to insert to any parent nixpkgs version:

pkgs = import nixpkgs { 
  inherit system;
  overlays = [ inputs.swayfx.overlays.insert ];
};

Enable swayfx, using the sway module (unstable):

programs.swayfx = {
  enable = true;
  package = pkgs.swayfx;
};

Or, as a workaround for the current stable nixpkgs:

programs.swayfx = {
  enable = true;
  package = pkgs.sway.override { 
    sway-unwrapped = pkgs.swayfx-unwrapped;
  };
};

Testing

Passes garnix ci on my fork: https://github.com/ozwaldorf/swayfx/runs/23469316022. On a side note, it might be worth considering enabling on this project

[ozwaldorf]

Side comment, #257 might break being able to use swayfx directly in the sway nix/hm module in the future

[WillPower3309]

Side comment, #257 might break being able to use swayfx directly in the sway nix/hm module in the future

good callout here, I am not sure how to proceed with that PR. In the least we need a sort of RFC

[WillPower3309]

LGTM! Thanks for the work here :)