nix-community / nixGL

A wrapper tool for nix OpenGL application [maintainer=@guibou]
677 stars 78 forks source link

feat: add flake #89

Closed lovesegfault closed 2 years ago

lovesegfault commented 2 years ago

This adds a simple flake to the repo with the nixGLIntel and nixVulkanIntel packages, since they are the only one that evaluate purely.

It also exposes an overlay which just adds the nixgl attr to pkgs.

SuperSandro2000 commented 2 years ago

I would be for just adding everything even if it does not eval purely.

lovesegfault commented 2 years ago

We could also just remove the packages portion altogether and make the flake only export the overlay, which IMHO is already a huge usability win for those using flakes.

lovesegfault commented 2 years ago

I would be for just adding everything even if it does not eval purely.

Doesn't work since it causes even basic flake commands (e.g. flake metadata) to fail

guibou commented 2 years ago

Exposing the overlay is great because it will force the upstream user to use the same nixpkgs for both their project and nixGL (which will ensures compatibility).

"pure" packages can still be exposed for convenience, but we need to document that the user must make nixgl inputs.nixpkgs "follows" their own nixpkgs.

lovesegfault commented 2 years ago

So, I thought about this more and IMHO only exposing some packages is more confusing than exposing none, and since we already expose the overlay the package is kind of pointless.

So I refactored this to make a flake that just exposes the overlay, which should be good enough, and also means we have no flake inputs :)

guibou commented 2 years ago

Just for my knowledge, is there a reason to exposes the overlay instead of just exposing the nixGL.nix file. Then user can decide if they want to callPackage on it directly, or use it in an overlay? That's just a naive question, we can merge without that.

However, could you please add a line in the readme about flake usage?

lovesegfault commented 2 years ago

Just for my knowledge, is there a reason to exposes the overlay instead of just exposing the nixGL.nix file. Then user can decide if they want to callPackage on it directly, or use it in an overlay? That's just a naive question, we can merge without that.

It's just more of a hassle to do that, as-is the user can still control the callPackage by calling .override on pkgs.nixgl.

It boils down to flakes having a predetermined set of valid outputs (overlay, packages, lib, defaultPackage, modules, ...) and "thing you need to callPackage on to use" not really fitting neatly into any of them IMHO.

Probably the thing we wanted was to expose all the nixgl attrs as flake packages, but the purity issue makes that impossible.

However, could you please add a line in the readme about flake usage?

Done :)

lovesegfault commented 2 years ago

@guibou Friendly merge ping, anything else I need to do? :)

guibou commented 2 years ago

Friendly merge ;) @lovesegfault Thank you!