!UUqahLbShAYkkrXmKs:matrix.org

DevOS

37 Members
Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga10 Servers

Load older messages


SenderMessageTime
26 Jul 2021
@blaggacao:matrix.orgDavid 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@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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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@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@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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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
@blaggacao:matrix.orgDavid 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@kraftnix:matrix.orgthanks for all the answers, i definitely have a better grasp of the interconnections now 👍️17:03:09
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgguys, check out this cancer https://github.com/NixOS/nixpkgs/pull/13158517:26:25
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgit was very interesting experience 😁17:26:41
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgwhat would be the easiest way to test runtime of everything?17:27:12
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgor is it "nixops v1 works, all good"17:27:22
@timdeh:matrix.org@timdeh:matrix.orgI suppose you could iterate over pythonPackages and just count the backtraces 😆17:27:48
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgu wot now mate17:28:09
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.org😆17:28:19
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgwelp, it failed yet again17:34:30
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.organd again :(17:50:35
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgdo you guys know how ofborg works? would love to execute that job locally17:50:51
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgwelp19:02:32
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orgits over 19:02:34
@gytis-ivaskevicius:matrix.org@gytis-ivaskevicius:matrix.orghttps://github.com/NixOS/nixpkgs/pull/13158519:02:35
@pachumicchu:myrdd.infoPacman99This is relevant: https://github.com/NixOS/rfcs/pull/8822:44:07
@pachumicchu:myrdd.infoPacman99 * I guess this is relevant: https://github.com/NixOS/rfcs/pull/8822:44:18
@pachumicchu:myrdd.infoPacman99I think you would have to start with a warning that the python2 packages are going to be removed22:44:42

Show newer messages


Back to Room ListRoom Version: 6