<arianvp>
Does anybody have any clue how the stuff in nixos/modules/misc/nixpkgs.nix works?
<arianvp>
localSystem (the parameter for nixpkgs) is defined in terms of system (which is 'deprecated')
<arianvp>
and localSystem is set to localSystem = { system = system; } but its description says it should be any of lib.systems.examples.*
<arianvp>
but non of those have the format { system; = system; } , but { config = <>; platform = <>; }; instead
<arianvp>
it's all really confsusing, and the docs contradict eachother in multiple places and have examples that don't seem correct
<gchristensen>
arianvp: you probably want roberth
<arianvp>
oh wait, I see localSystem has apply = lib.systems.elaborate;
<arianvp>
oh no.. :D
<niksnut>
arianvp: don't feel bad, I don't understand it either
<gchristensen>
me either :(
<arianvp>
:'D
<gchristensen>
I would have expected those parameters to be passed in to the NixOS function at call time
<arianvp>
basically, I wanted to get rid of the `system` paremeter in all eval-config.nix calls, as it seems redundant, but then I got really confused
<niksnut>
unfortunately cross-compilation support imposes a cognitive burden even if you don't use it
<gchristensen>
right
<arianvp>
So I guess nixos used to only have the `system` parameter. then later `localSystem` and `crossSystem` where added, and for backwards compatibility we define those in terms of `system` ?
<gchristensen>
nixpkgs itself accepts just the "system" parameter, too
<roberth>
arianvp: I believe you're right about nixpkgs.nix evolution with localSystem and crossSystem added later
<roberth>
IMO system should always have been the system that is produced, and only a buildSystem option needed to be added
<ekleog>
IMO the localSystem / crossSystem “simplification” is a mistake and we should be using only buildPlatform/hostPlatform/targetPlatform (with build and host that default to builtins.system, and target that defaults to host)
<ekleog>
like, to get a custom targetPlatform for gdb (which shouldn't be too hard in theory) I've found nothing better than gdb.override { stdenv = (import <nixpkgs> {}).stdenv.override { targetPlatform = (import <nixpkgs> {}).lib.systems.examples.riscv32; }; } ; which is… not really optimal
<arianvp>
roberth: IMO, we should just drop alll those parameters from NixOS and just only allow settings pkgs
<arianvp>
setting pkgs*
<arianvp>
the whole nixpkgs.config module is rather confusing (IMO)
<arianvp>
(I guess that is sort of what you did with the pkgs.nixos function, but I don't see why we dont make that default)
<arianvp>
roberth:what are your thoughts on that, given you've been in this rabbit hole before?
Jackneill has joined #nixos-dev
<roberth>
it's actually an instance of a more general issue where you want to make things easy in a module by providing a bunch of options that in turn construct something, but if you already have that something, using the ready-made thing you have is going to be very awkward
<roberth>
arianvp: so if you provide an option for the whole nixpkgs.pkgs, how do you deal with modules that set nixpkgs.config. What should that mean? Does the module provide a mere suggestion that the user wants to override by setting pkgs directly? Should the nixpkgs.config now describe an assertion about nixpkgs.pkgs? Suddenly all these definitions' intents are unclear.
<arianvp>
honestly I think config should be deprecated as well.
<arianvp>
but that might be controversial
<arianvp>
because now you cant build up the pkgs config modularily.
<roberth>
yeah nixpkgs' config has no merge function, which is weird when integrating into NixOS
<roberth>
the least that should be done is to write more sanity checks for the nixpkgs.nix module
<roberth>
to fix the confusion, we'd need something like sum modules (as in sum types): either specify nixpkgs.pkgs or specify nixpkgs.{config,system,overlays,...}
<roberth>
it allows overlays to be added modularly
<roberth>
but whether that's a good thing depends... on `super` dependencies
<arianvp>
is that a good idea though?
<arianvp>
im not convinced that is desirable
<roberth>
ok, suppose we need a patched Nix for some feature in hercules-ci-agent. We'd add it to our `{,nixops-}profile.nix` that people import into their deployment specs. We could set `nix.package` to set the package for nix-daemon, but any other packages that depend on `pkgs.nix` still see the wrong version
<roberth>
in such a case adding an overlay that redefines `pkgs.nix` to be the patched version ensures that the whole system has a consistent Nix version
<roberth>
s/feature/hotfix
<roberth>
I guess it's better than not defining the overlay, but still doesn't provide guarantees :/
Synthetica has joined #nixos-dev
FRidh has joined #nixos-dev
rsa has quit [Ping timeout: 258 seconds]
FRidh has quit [Quit: Konversation terminated!]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
pie___ has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
<matthewbauer>
ekleog: you should do `(import <nixpkgs> { crossSystem = { system = "riscv32-linux"; }; }).buildPackages.gdb`
<matthewbauer>
the structured system thing was IMO a bad idea
<gchristensen>
structured system?
<matthewbauer>
arianvp: yeah I agree on getting rid of all of the options.nixpkgs.* things. it should just be a package set. all of the extendOverlays makes things very confusing
<matthewbauer>
gchristensen: i'd like to be able to do just `import <nixpkgs> { crossSystem = "riscv32-linux"; }` which is much cleaner IMO
<matthewbauer>
maybe we could add compatibility for that though
<gchristensen>
ah
<ekleog>
matthewbauer: Hmm I guess that would work too, thanks! Though I'd love if it was possilbe to just `(import <nixpkgs> { targetPlatform = "riscv32-linux"; }).gdb`, as using `.buildPackages` look like a hack to me -- still a better hack than what I had before
<matthewbauer>
ekleog: yeah maybe we can add support for that. at least some handling so `(import <nixpkgs> { target = "..."})` -> `(import <nixpkgs> { crossSystem = ""; }).buildPackages`
<matthewbauer>
we don't want to go crazy with all of these options, but it seems like a nice sugar for that
<ekleog>
yeah, that's why I was thinking we might be better off dropping all `system`-related names and using only `*Platform` -- would also make one less weird semantic paragraph in the docs :)
<ekleog>
like `import <nixpkgs> { crossSystem = ""; }` would just become `import <nixpkgs> { hostPlatform = ""; }`
<matthewbauer>
yeah honestly target and platform are poorly defined. i'd be fine with dropping the naming altogether
pie_ has joined #nixos-dev
<matthewbauer>
ekleog: part of the problem is we don't really support canadian cross right now. so how should build = a, host = b, target = c be handled?
<matthewbauer>
i'm not 100% if it is worth supporting though
justanotheruser has joined #nixos-dev
justanotheruser is now known as Mr_Notheruser
<clever>
gchristensen: what was the link to the nixos darwin infra? i lost it again
<gchristensen>
check nixos-org-configurations' mac directory
<clever>
ah, thanks
<clever>
gchristensen: and the initial disk image the macs boot from, does this nix code include it, or will i need to image a mac somehow?
<gchristensen>
check notes.md on how the initial disk image is created
<clever>
ah
<gchristensen>
obviously the actual disk image is not public :)
Mr_Notheruser has quit [Ping timeout: 252 seconds]
<gchristensen>
I open things in firefox and then use screenshots.firefox.com :P
<clever>
xterm has a native dump to (svg|html) button
<clever>
if i wanted a png, i would just use xfce and imgur
<gchristensen>
nice
<clever>
you can even see my xterm version in the svg source, lol
<clever>
gchristensen: i also notice nixops being "weird", --build-only gave that small diff, but --copy-only gives a different diff, it added itself to the ssh keys!
<gchristensen>
O.o
<clever>
the none backend generates its own keypair on first deploy, and inserts it into physical.nix, to open root up
<clever>
--build-only doesnt make it, but --copy-only and beyond to