improve package overriding inside home-manager

[musjj]

The final overriden package is now accessible by the user via config.ags.package. This is useful if the user wants to re-use the package somewhere else.

extraPackages will also now add the packages into ags's environment, instead of just modifying buildInputs (which effectively does nothing).

[Aylur]

the extraPackages expects gobject based libraries to add to gjs's runtime
they need to be passed to buildInputs in order for wrapGAppsHook to work, they don't work if you add them to PATH

[musjj]

Oh, I see, didn't know that was the intended usage. But still, in home-manager the extraPackages option is usually used to add packages to the PATH, by convention.

Couldn't the user just use with pkgs; ags.overrideAttrs (oldAttrs: { buildInputs: [ cowsay ] ++ oldAttrs.buildInputs })? It's more wordy, but it conveys the intention better.

Or should there be a new option for this? It could be called extraBuildInputs.

[Aylur]

They could write it out yes, but the point of the home-manager modules is to not write it out imo.
I searched through some NixOS options and the extraPackages is used mostly for PATH and additional runtime packages, for example python programs, thats why I went with it

[musjj]

Yeah, but unfortunately putting packages in buildInputs won't make them show up in the program's PATH, at least not without extra logic.

What about having extraPackages put the packages both in buildInputs and the PATH? The downside is extra build time if the user doesn't need both of them.

[Aylur]

I guess we could do that, but why not just use home.packages? do you want to have a program only in gjs's PATH and not globally?

[musjj]

I was trying to use ags from inside a service, but I realized that I could've just used the Environment option for that (or just make my own wrapper).

I decided to go for a finalPackage option instead, which seems more idiomatic in the nix world (sorry for the force-push).