Extra arguments in configuration.nix with default values no longer work
#7272
Comments
|
Note: reverting #6794 fixes my issue, but I can't keep it reverted on my private nixpkgs clone forever... |
|
In this precise example, the default value can be moved as an option definition, either by declaring a specific option for it, or as follow: In general, this is not possible today as we have no equivalent to returning a value equivalent to the absence of an attribute. More over, we cannot solve this when we generate the attribute set arguments, as this would imply that we already have to result of the evaluation of the module that we are trying to call. This is indeed a regression if the arguments are used to decide which imports are used. If we want to solve this case, then we would have to restore a notion of precedence, where the extra arguments given to the I am not sure if we want to fix it if nobody has a concrete use-case. |
|
@nbp Thanks, your suggestion fixes the example I gave. However, now I am getting an infinite recursion due to exactly the problem you mentioned, of default arguments deciding which imports are used. In fact, if I simplify the configuration to the following very short This is the exact error for the short example: I guess this qualifies as a use case? Or is there a better way of including the Hydra module into one's |
|
@wizeman, can you detail how you provide a non-default value to your modules? |
|
Sure... well, it's a bit complicated to explain but I'll try. First off, I have files such as: ... each of which is a valid On a second level, I have a file called It basically just imports the However, building everything on my laptop would be a nightmare. So finally, I have a file called However, the custom software packages which are stored on my home server are in different paths than what I have on my laptop. |
|
@wizeman: Ah, i'm doing something similar to what you're doing here and if it comes to Hydra, I'm directly importing the module from the source derivation like this. |
|
@aszlig Right, but you have the luxury of fetching Hydra from github, always from the same location. I think the problem here is that the location of my Hydra checkout depends on whether I'm building from my laptop (the default) or from my server (explicitly overriding the location). This used to work, but with the changes from #6794 it doesn't work anymore. Note that I'm sometimes building Hydra with custom changes. In particular, I just want to modify my git checkout locally, push my changes to my server and have everything just work out transparently. I don't have (nor do I wish to have) a (private or public) Hydra git repository accessible from both my laptop and home server, as it would either be more insecure, or I'd have to manually be specifying the git rev and hashes all the time. I just want to be able to build from local checkouts... |
|
@wizeman: It doesn't need to be from GitHub, it can be fetched from a local path as well (just replace So for example: import "${/path/to/your/hydra/source}/hydra-module.nix" |
|
@aszlig Your suggestion doesn't seem to work. This minimal { config, pkgs, lib
, hydra_path #1st syntax: ? "/root/src/localrepos/hydra"
, ... }:
with lib;
let
hydraModule = import "${hydra_path}/hydra-module.nix";
in {
#2nd syntax: _module.args.hydra_path = lib.mkDefault "/root/src/localrepos/hydra";
imports = singleton hydraModule;
} |
|
@wizeman: First of all, I'd make sure that the Hydra sources are a path and not a string, so that it will end up in the store. How are you evaluating this configuration? A quick check roughly similar to your But the last one is using the path as a module argument, so testing that now as well... |
|
@aszlig I don't understand... why would I want the Hydra sources in the store? To answer your question, this is how I am evaluating it:
This is the result: |
|
@aszlig Also, you're not using a default value for your |
|
Okay, was able to reproduce it and it only really happens if the argument is passed to an |
|
@wizeman, so you are using the same config within hydra, where you provide a non-default value and call the expression your-self, or with NixOS lib's which does not provide this argument. So far I have ideas on how to make a work-around, but it would imply that you modify the evalModule call of NixOS, which is not what you are looking for. I think I can do something like: would that be ok for you if this is doable? |
|
@nbp Your suggestion sounds pretty great to me. Thanks! |
This causes an infinite recursion on evaluation if we import something from a module argument. So until we have an importsArgs module attribute we're going to refer to ../../nixpkgs-path.nix. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
Sorry for the delay, I will try to come-up with an implementation by the end of the week. |
…are eagerly provided by the module system.
…are eagerly provided by the module system.
|
@wizeman , I think we now have a special argument again for 1modulePath`, which can be used in the same way as you used to. Can you confirm that it works fine for you? |
|
@nbp I've tried it in a few different ways and I am still getting an infinite recursion, but I'm probably not doing it right. Could you show me a small example of how that special argument could be used to solve this issue? |
|
@wizeman Basically, you would have to do something similar to what you pasted a while ago in #7272 (comment) , except that instead of having it being named oh … and I noticed that we would have to change the way we process arguments in |
|
@wizeman I was re-reading what you described above, and I wondering why you need the hydra_path and other to be arguments of the modules, and not argument of a function which produces a module? What I mean is that your configuration would become something like: where the |
|
Closing as this issue is solved by #11106. |
…agerly provided by the module system.
|
The supposed fix seems to have gotten reverted 4y ago and I just ran into this issue again. Reproducer configuration.nix: { foo ? { ... }: {}, ... }:
{
imports = [ foo ];
}Trace: |
This makes it possible to evaluate my configuration via build.nix It also allows you to specify a custom meta attrset without modifying meta.nix which is useful for building purposes/hardware combinations other than your local one I couldn't put this in default.nix unfortunately because a NixOS configuration file can't have custom arguments (NixOS/nixpkgs#7272)
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
stale
bot
removed
the
2.status: stale
veprbl
added
the
2.status: stale
After #6794 was merged, my NixOS configuration started to fail with the following error:
My
configuration.nixhas the following contents:{ config, pkgs, lib , rg_path ? "/root/src/rg" , ... }: let rgpkg = import "${rg_path}/default.nix" {}; in (...) environment.systemPackages = with pkgs; [ (...) rgpkg ];I'm guessing it's some issue related to arguments with default values not being handled correctly after the
lib/modules.nixrefactoring?cc @nbp @shlevy
The text was updated successfully, but these errors were encountered: