Skip to content
This repository has been archived by the owner on Jan 25, 2024. It is now read-only.

Add overlays #84

Closed
wants to merge 2 commits into from
Closed

Add overlays #84

wants to merge 2 commits into from

Conversation

a-kenji
Copy link

@a-kenji a-kenji commented Apr 7, 2022

Summary & Motivation

Add overlay to outputs of the flake.
That way people can compose the unreleased versions better.

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: #77

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;
Copy link
Member

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.

Copy link
Author

@a-kenji a-kenji Apr 24, 2022

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!

Copy link

@tomberek tomberek May 20, 2022

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:

  1. packages: here is a composed package that I, the author, have tested
  2. 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
  3. 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;
};
Copy link
Member

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.

@a-kenji a-kenji closed this Apr 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

flake.nix should provide an overlay
3 participants