accelbread
commented
8 months ago This I am a bit torn on.
On one hand, if a flake has a lib output, it is reasonable to put it in the overlay to allow easier use, and avoid the flake having to declare that.
On the other hand, there a few issues.
For one, the lib would need to be composable with nixpkgs lib. Most flakes I have seen with lib outputs, while this would work, are not designed with that in mind. Usual use would be use lib for nixpkgs and flake-name.lib for that flake's lib separately. Even if a flake does not use a name currently in nixpkgs, a future update to nixpkgs could cause the overlay to mask an incompatible function and cause hard to debug issues. Flakes that do intend to compose also usually don't put their functions in the top-level of lib but in lib.flake-name. This would be the better general approach but requires knowing that that flake-name name should be. As an edge case, a flake lib which is made extensible and relies on extending itself could malfunction when combined with nixpkgs lib, as we'd have to use nixpkgs' extensibility.
Second, with packages, there is a distinct difference between using the overlay and using the flake package outputs. Flake package outputs are built with the flake's deps, but overlays use deps as supplied by the user. For lib code, the functions would be the exact same whether used from the flake output or the overlay, so theres much less value. To make them useful, the lib would have to be defined as an overlay that uses lib functions from prev and have the regular overlay generated from that. This would be non-standard and wouldn't make sense as default imo.
Third, as a user of the flake, I'd find it surprising if the overlay modified lib, especially because it could conflict with my own lib modifications.
Currently to add lib to the overlay, namespacing under flake-name, you could do something like:
{
inputs.flakelight.url = "github:accelbread/flakelight";
outputs = { flakelight, ... }:
flakelight ./. rec {
pkgs.hello = { hello }: hello;
lib = { test = x: x; };
overlay = final: prev: { lib = prev.lib.extend (final: prev: { flake-name = lib; });};
};
}The above unfortunately is not simple, but would have both lib.flake-name and the package in the output overlay. We could make a libOverlay option to directly set lib overlays though that would be non-standard. Also I'm not sure putting lib in the overlay is a good idea in the first place.
So I am leaning towards not doing lib automatically since its unclear what the automatic thing to do is. There does not seem to be a clear "good way" to do it. I could be convinced otherwise though.
noverby
Right now, packages are available in
overlay.default.Wouldn't it make sense to also expose
libinoverlay.default, so you can define values and helper functions, that can be used globally?