In reply to @kraftnix:matrix.org

what's the current suggested way for adding new packages which are already defined in some external flake?

the docs in develop for pkgs seem to be out of date, but the nvfetcher docs seem to suggest adding it to sources.toml then defining an overlay as is done with manix, to override pname, version and src

I tried doing this with rnix-lsp, which I can build fine if I separately clone it, but if I just follow the same override syntax as manix I get a cargoSha256 error.

I'm guessing this is overall not the correct way to do this, does anyone have some suggestions?

There are two ways: nixpkgs's overlays or flake's follows. With the follows-way you bet on memoizing the nixpkgs evaluation that a certain package requires to build. Memoization works if the import call signature of nixpkgs is equal, for example import nixpkgs { config = {}; overlays = [];} With the overlays way, you "patch" external instructions into the pkgs namespace. This is why pkgs.addOVerlay or pkgs.extend do a full re-evaluation of the entire pkgs namespace to calculate a new fixed-point (taking into account the added packages).

sources, on the other hand is itself an overlay that adds the pkgs.sources namespace that holds reference to a source's package name, sourcecode and version information.

In reply to @kraftnix:matrix.org

what's the current suggested way for adding new packages which are already defined in some external flake?

the docs in develop for pkgs seem to be out of date, but the nvfetcher docs seem to suggest adding it to sources.toml then defining an overlay as is done with manix, to override pname, version and src

I tried doing this with rnix-lsp, which I can build fine if I separately clone it, but if I just follow the same override syntax as manix I get a cargoSha256 error.

I'm guessing this is overall not the correct way to do this, does anyone have some suggestions?

There are two ways: nixpkgs's overlays or flake's follows. With the follows-way you bet on memoizing the nixpkgs evaluation that a certain package requires to build. Memoization works if the import call signature of nixpkgs is equal, for example import nixpkgs { config = {}; overlays = [];} With the overlays way, you "patch" external instructions into the pkgs namespace. This is why pkgs.addOverlay or pkgs.extend do a full re-evaluation of the entire pkgs namespace to calculate a new fixed-point (taking into account the added packages).

sources, on the other hand is itself an overlay that adds the pkgs.sources namespace that holds reference to a source's package name, sourcecode and version information.

Yeah so I eventually got it working by adding rnix-lsp to the toplevel flake.nix and adding this ugly element to channels.nixos.overlays:

(fi: pr : { inherit (inputs.rnix-lsp.packages.x86_64-linux) rnix-lsp; })

I had attempted to do it via sources like manix, but that error I ran into is because I need to update cargoSha256 for the new src, however I couldn't find out how to get the new cargoSha256, I gave up once I saw an unresolved issue on nixpkgs by nrdxp regarding this exact issue with rnix-lsp

at least the above hacky solution gets it working for me, although I would prefer a cleaner solution. I am not sure exactly what you mean by how I could use follows, would simple setting rnix-lsp.inputs.nixpkgs.follows = "nixos"; be sufficient the flake to override my rnix-lsp package?

In reply to @kraftnix:matrix.org
from repl it doesn't look like rnix-lsp provides an overlay, so in that case is the hacky way the right way to go about this? also I'm guessing this would break rnix-lsp if I had multiple architectures

In reply to @kraftnix:matrix.org
from repl it doesn't look like rnix-lsp provides an overlay, so in that case is the hacky way the right way to go about this? also I'm guessing this would break rnix-lsp if I had multiple architectures