-
-
Notifications
You must be signed in to change notification settings - Fork 40
Conversation
Add `rnix-lsp` `overlays` to the flake outputs, in order to be directly consumed by other flakes. Provides 2 overlays: - default: with package named `rnix-lsp`, so people can overwrite their existing configuration - nightly: with package named `rnix-lsp-nightly`, so people can opt in to this package on a case-by-case basis Also for now still uses the `overlay` attribute, for backwards compatibility, is that needed? fixes: nix-community#77
rnix-lsp = self.packages.${prev.system}.rnix-lsp; | ||
}; | ||
nightly = final: prev: rec { | ||
rnix-lsp-nightly = self.packages.${prev.system}.rnix-lsp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this rather error-prone to not use final
/prev
here, but another nixpkgs? I'd suggest to define the package in an overlay and expose the package from the overlay in self.packages
actually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this rather error-prone to not use final/prev here, but another nixpkgs?
Oh yes, you are right. I assumed that nixpkgs
would be specified in the follows
attribute, but It makes sense that I shouldn't!
I'd suggest to define the package in an overlay and expose the package from the overlay in self.packages actually.
Oh, that is quite neat, I will try that! My first thought was to write a function that we expose at the overlay
and the self.packages
.
Thank you for the review!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposal: proto-derivations
I've been using this approach as a way to expose "proto-derivations" (the callPackage design pattern where you have a function that when given arguments+evaluated will produce a derivation). This is then a very re-usable thing that avoids many of the problems with overlays, but can still be utilized if so desired. Other consumers can use some-flake#proto.default
in any way they wish.
{
outputs = {self,...}: {
packages.<system>.default = nixpkgs.legacyPackages.<system>.callPackage self.proto.default {inherit naersk-lib;};
packages.<system>.optimized = nixpkgs.legacyPackages.<system>.callPackage self.proto.default {
optimized = true;
inherit naersk-lib;
};
overlay.default = final: prev: final.callPackage self.proto.default {};
# proposing a standard that we expose "proto-derivations" like this
proto.default = {stdenv, lib, cargo, naerst-lib, optimized ? false }: naersk-lib.buildPackage {
pname = "asdfas";
};
}
}
You can express all the variations of:
- packages: here is a composed package that I, the author, have tested
- overlays: here is a way to deeply inject this into my nixpkgs packageset. You, the user, must deal with the complexity of the fixed point
- proto: here is a way to completely call the function from scratch. You, the user, must provide all the inputs.
@thufschmitt thoughts about having this be a part of the output schema?
}; | ||
}; | ||
overlay = overlays.default; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The indentation seems quite off here.
Summary & Motivation
Add
overlay
tooutputs
of theflake
.That way people can compose the unreleased versions better.
Add
rnix-lsp
overlays
to the flake outputs, in order to be directlyconsumed by other flakes.
Provides 2 overlays:
- default: with package named
rnix-lsp
, so people can overwrite theirexisting configuration
- nightly: with package named
rnix-lsp-nightly
, so people can opt into this package on a case-by-case basis
Also for now still uses the
overlay
attribute, for backwardscompatibility, is that needed?
fixes: #77