ChanServ changed the topic of #nixos-nur to: Nix User Repository || ||
kreisys has joined #nixos-nur
<kreisys> Hey guys I'm not super clear on how to consume modules
<kreisys> I follow what's described in the readme (nur-no-pkgs) but get the throw anyways
<kreisys> Also directly from nix-repl so I don't think it's my config...
<kreisys> That's strange... Seems to affect some ppl's modules but not others. peel.modules throws, ma27.modules throws but tilpner.modules seem fine...
<kreisys> my metric is
<kreisys> nix-instantiate --expr '(import (builtins.fetchTarball "") {})' --eval
<kreisys> for example
<kreisys> It's not immediately apparent to me what's causing the difference...
nur-bot has joined #nixos-nur
<nur-bot> yurrriq: da72f1698a -> 5570c06dc9 (
nur-bot has quit [Client Quit]
<wirew0rm> hey
<wirew0rm> is it possible to add additional systems to from a nur repository?
<ma27> kreisys: I guess that this is related to how modules are configured in the repositories. I can have a look at this in my repo, but I'm currently passing modules around by manipulating $NIX_PATH %)
<wirew0rm> or does anyone have an idea on how to package a cross compilation toolchain in the nur?
<tilpner> Yay?
<tilpner> wirew0rm - Look at the source, you don't need to alter lib
<tilpner> kreisys - I was going to say "mine are paths, others might be functions", but peels appear to be functions too
<tilpner> *paths too
<kreisys> I've been pulling my hair all afternoon over this lol
<kreisys> I really can't spot the culprit
<tilpner> Oh
<tilpner> Duh
<tilpner> peel does "// import ./pkgs { inherit pkgs; }"
<tilpner> So to find out if "modules" is overwritten, it needs to eval pkgs
<tilpner> While I do "pkgs' // { modules = ...; }"
<tilpner> So modules is always the last defined value, and it never needs to eval pkgs'
<kreisys> Well that's what the template suggests to do
<kreisys> So I guess it's kind of an issue
<kreisys> Oh no no my bad lol
<kreisys> I used peel as a template. That's on me :P
<kreisys> mmm... switching the order doesn't seem to make a difference
<Mic92> kreisys: is not an example in the README already how to load modules?
<Mic92> *is there not...
<kreisys> It's not working for all modules
<kreisys> Specifically it didn't work for me for ma27 and peel modules but works fine for tilpner
<tilpner> Are you sure? How are you checking?
<Mic92> it should import there
<tilpner> Mic92 - No, it should not
<tilpner> Mic92 - Path modules can be deduplicated, function modules can't
<Mic92> ok
<tilpner> If you import the same function modules from two different places, everything explodes
<tilpner> With paths it's fine
<Mic92> Ok. then in the long term should be also checked during evaluation.
<Mic92> *this should be
<tilpner> We've talked about this ages ago
<Mic92> I remember
<Mic92> I think one problem with this is approach is, if someone forgots to add dependency correctly.
<tilpner> In this case, I think the set merging order that's causing the error
<tilpner> *think it*s the
<tilpner> I don't see how function modules help with that?
<kreisys> I tried to switch my pkgs to a file containing only '{ pkgs }: {}'
<kreisys> it still exploded :|
<Mic92> It does not help
<tilpner> So "this approach" is "modules.*", not "path modules"
<tilpner> :D
<tilpner> I've used the tcc one a few times
<tilpner> But now they're disabled
<tilpner> Check files.nix too
<tilpner> It uses evil activationScripts
<Mic92> you are also messing up sandbox builds
<tilpner> I don't see how it would trigger in a well-behaved sandbox-build
<tilpner> But I generally agree
<tilpner> Oh well. I learned about binfmt_misc and couldn't handle the responsibility
<Mic92> binfmt is not namespaced.
<Mic92> so it will still use the global interpreter for files executed in the sandbox
<Mic92> Hopefully they will fix this in future becaus binfmt then would actually becomes useful.
<kreisys> Is that a reasonable metric?
<kreisys> I have to run without --eval first so that the path is generated, then with --eval so that it doesn't complain that it doesn't eval to a derivation
<kreisys> I'm basically just trying to get the path and I have no idea how pkgs get thrown in
<tilpner> Mic92 - Yes, but why would a sandbox build try to blindly execute .c files, knowing it usually doesn't work?
<tilpner> Of course it could break builds specifically desgined to be broken by binfmt
<tilpner> But I don't think there's a single build in nixpkgs which would be affected by this
<Mic92> it becomes interesting, when you you overrule shebangs.
<Mic92> I am pretty sure somebody is abusing that:
<Mic92> kreisys: probably this should become an issue ticket in NUR
<Mic92> then we could ask some nixos module experts.
<kreisys> kk
<tilpner> Well...
<tilpner> I don't know what ma27 intended, but that thing looks like it's still using pkgs
<tilpner> Sure, it takes a nixpkgs argument, but it's not being passed, so it falls back to using the pkgs argument
<tilpner> It uses lib from pkgs to provide the modules
<tilpner> Solution: don't
<tilpner> And I've already explained peels problem
<ma27> tilpner: as I said, I distribute modules via NIX_PATH in my setup ATM, last time I actively checked, NUR didn't support module distribution
<ma27> when I have time for this, I'll try to fix this
<tilpner> Oh, you're right. That was before I connected, but you did imply that you're not using the NUR module mechanism
<wirew0rm> tilpner: i'll have to look into that... i can see that i can give a struct like in, but I didn't yet figure out how and when is invoked which also needs some modifications to account for new systems. I guess I'll just have to read the code some more :)
<kreisys> tilpner: I still don't understand what's breaking peel
<kreisys> I'm assuming that's breaking mine as well
<kreisys> I only have one simple module that basically just configures my cachix
<kreisys> no fancy functions or anything. I don't understand why it's breaking
<tilpner> kreisys - What is the value of this expression? let x = { foo = 42; } // bar; in
<kreisys> 0
<tilpner> Huh?
<kreisys> sorry lol I elbowed the keyboard
<kreisys> where's bar
<tilpner> Exactly
<tilpner> You need to look at bar, "evaluate" it
<tilpner> So when you do { modules = ...; } // something_that_involves_pkgs, you can't access .modules without evaluating pkgs
<tilpner> And that's why it explodes
nur-bot has joined #nixos-nur
<nur-bot> moredhel: 35fe527ce1 -> bc0bf06b71 (
nur-bot has quit [Client Quit]
<tilpner> wirew0rm - Okay, I'll refine what I said. only has a small selection of the possible systems you could represent
<kreisys> tilpner: but it still breaks if I flip it
<tilpner> wirew0rm - You can create new combinations without modifying lib. I don't know if it's possible extend the number of possible combinations without touching lib though
<kreisys> (import ./pkgs { inherit pkgs; }) // { modules = ...; ... }
<tilpner> (And by "create new combinations" I really mean "define combinations not defined in")
<kreisys> still fails the same way
<tilpner> Do you have your repo pushed somewhere?
<kreisys> my repo is in nur
<tilpner> But it's still using the old form
<kreisys> oh I'm just trying to fix it in a nur-combined checkout
<kreisys> I tried flipping peel's default.nix
<wirew0rm> tilpner: ok, now we're on the same page. I guess then I'll need my own private nixpkgs fork. I need to add xtensa as a supportet cpu to the parser and stuff.
<kreisys> I just don't want to push a "fix" that doesn't fix
<kreisys> I changed repos/peel/default.nix to
<kreisys> and it still displays the same behaviour
<tilpner> Well, I was slightly wrong
<tilpner> But I fixed it!
<tilpner> Comment out the trailing // part in your pkgs/default.nix
<tilpner> Who needs hydra anyway
<tilpner> I was wrong in that order seems to be irrelevant
<wirew0rm> tilpner: i'm trying to get a nice toolchain for the esp32, but I've more or less given up on getting something worth including in upstream nixpkgs. basically it needs pinned versions for gcc, newlib, etc and patches. this is what i tried some time ago: Now that I started playing with NUR, I thought maybe it could be the place for
<wirew0rm> an experiment like that :)
<tilpner> But right in that the attrset keys can't depend on pkgs
<kreisys> wait is that mine or peel's
<tilpner> Should be yours
<tilpner> So, uhh, no attributes that appear on different platforms
<tilpner> Just have it deny the build like nixpkgs does
<kreisys> That won't break my darwin travis run?
<tilpner> How would I know?
<tilpner> If your travis build *everything*, maybe
<tilpner> But it doesn't have to
<tilpner> wirew0rm - That sounds like Fun™. Good luck :/
<kreisys> well I guess I'll just push it and see what happens
nur-bot has joined #nixos-nur
<nur-bot> kreisys: b386add07a -> 52394e78fe (
nur-bot has quit [Client Quit]
<wirew0rm> tilpner: thanks :) let's just say I sure learned a lot already trying to figure this all out ;)