26 Jul 2021 |
David Arnold (blaggacao) | 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.
| 16:20:48 |
@kraftnix:matrix.org | 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?
| 16:35:19 |
David Arnold (blaggacao) | The way you did is already akin to the follows way: rnix-lsp.inputs.nixpkgs.follows = "nixos"; would at least make sure that dependencies are reused and rnix-lsp does not build off of a complety distinct nixpkgs version and hence dep tree. | 16:37:40 |
David Arnold (blaggacao) | On the other hand, if you'd want to avoid an extra nixpkgs evaluation and make use of memoization, it becomes relevant to examine how rnix-lsp actually imports nixpkgs . Assuming that it's import nixpkgs { config = {}; overlays = [];} we can be confident that any other such import get's evaluated only once and then is memoized. | 16:39:47 |
David Arnold (blaggacao) | * On the other hand, if you'd want to avoid an extra nixpkgs evaluation (reportatly taking 130MB of RAM, in any case: no scaling well) and make use of memoization, it becomes relevant to examine how rnix-lsp actually imports nixpkgs . Assuming that it's import nixpkgs { config = {}; overlays = [];} we can be confident that any other such import get's evaluated only once and then is memoized. | 16:40:27 |
David Arnold (blaggacao) | The main instantiation of nixpkgs done in fup , however does pass both, config and overlays`, henve you probably suffer one extra instantiation of nixpkgs. (but only one for any other such package that is added this way) | 16:42:15 |
David Arnold (blaggacao) | * The main instantiation of nixpkgs done in fup , however does pass both, config and overlays , hence you probably suffer one extra instantiation of nixpkgs. (but only one for any other such package that is added this way) | 16:42:29 |
David Arnold (blaggacao) | * The main instantiation of nixpkgs done in fup , however does pass both, config and overlays , hence you probably suffer one extra instantiation of nixpkgs. (but only one globally for any number of such packages that is added this way) | 16:42:52 |
@kraftnix:matrix.org | from repl it doesn't look like rnix-lsp provides an overlay, so in that case is the hacky to do what I did? also I'm guessing this would break rnix-lsp if I had multiple architectures | 16:45:57 |
@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 | 16:46:25 |
David Arnold (blaggacao) | 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 yep, in this case this is the right way. IN theory, you can even add packages directly via inputs.[...].mypackage to where you want to us them without going through an overlay, but I understand in this case you probably want to override the nixpkgs stock version. | 16:49:39 |
David Arnold (blaggacao) | 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 * yep, in this case this is the right way. In theory, you can even add packages directly via inputs.[...].mypackage to where you want to us them without going through an overlay, but I understand in this case you probably want to override the nixpkgs stock version. | 16:50:02 |
David Arnold (blaggacao) | If there are multiple architectures, all those who are supported by rnix-lsp outputs should work out of the box. | 16:51:31 |
@kraftnix:matrix.org | thanks for all the answers, i definitely have a better grasp of the interconnections now 👍️ | 17:03:09 |
@gytis-ivaskevicius:matrix.org | guys, check out this cancer https://github.com/NixOS/nixpkgs/pull/131585 | 17:26:25 |
@gytis-ivaskevicius:matrix.org | it was very interesting experience 😁 | 17:26:41 |
@gytis-ivaskevicius:matrix.org | what would be the easiest way to test runtime of everything? | 17:27:12 |
@gytis-ivaskevicius:matrix.org | or is it "nixops v1 works, all good" | 17:27:22 |
@timdeh:matrix.org | I suppose you could iterate over pythonPackages and just count the backtraces 😆 | 17:27:48 |
@gytis-ivaskevicius:matrix.org | u wot now mate | 17:28:09 |
@gytis-ivaskevicius:matrix.org | 😆 | 17:28:19 |
@gytis-ivaskevicius:matrix.org | welp, it failed yet again | 17:34:30 |
@gytis-ivaskevicius:matrix.org | and again :( | 17:50:35 |
@gytis-ivaskevicius:matrix.org | do you guys know how ofborg works? would love to execute that job locally | 17:50:51 |
@gytis-ivaskevicius:matrix.org | welp | 19:02:32 |
@gytis-ivaskevicius:matrix.org | its over | 19:02:34 |
@gytis-ivaskevicius:matrix.org | https://github.com/NixOS/nixpkgs/pull/131585 | 19:02:35 |
Pacman99 | This is relevant: https://github.com/NixOS/rfcs/pull/88 | 22:44:07 |
Pacman99 | * I guess this is relevant: https://github.com/NixOS/rfcs/pull/88 | 22:44:18 |
Pacman99 | I think you would have to start with a warning that the python2 packages are going to be removed | 22:44:42 |