<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...
<wirew0rm>
is it possible to add additional systems to lib.systems.examples 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
<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>
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 lib.systems.examples, but I didn't yet figure out how and when lib.systems.parser 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 x.foo
<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>
wirew0rm - Okay, I'll refine what I said. lib.systems.examples 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
<tilpner>
(And by "create new combinations" I really mean "define combinations not defined in lib.systems.examples")
<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>
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: https://github.com/wirew0rm/nixpkgs/tree/xtensa_esp32-none-elf_crossToolchain 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