Out of curiosity: is Bocchi the Rock the first anime you watched that is not action-focused and has no monsters or extraterrestrial/extradimensional invaders?

As for my recommendation (but it’s really a shot in the dark, given the scarce detail you provided), there’s an older anime called “hitoribocchi something something” (I’m too lazy too look up the name) that I remember being pretty funny.

There’s the readDir builtin, but I expect nix might complain if you use that

I can help too if you still have openings

IDK about the issue itself but I must say the discourse post does a mighty good job at explaining the reasons the guy was NOT suspended for and a really terrible one at explaining what they actually did suspend him for, except pissing off “the moderation team, in consultation with members of the Foundation board”.

Documentation isn’t stellar IMHO: I end up reading the nixpkgs sources most often than not (it probably depends on what you are doing, though)

That’s it! I love you, thanks!

Not sure what the issue is, but I hope this helps:

• Stuff added to home.sessionPath ends up in $HOME/.nix-profile/etc/profile.d/hm-session-vars.sh, which (in my system, at least) is referenced from ~/.profile.
• ~/.profile is only executed by login shells (ie. you have to logout and back in for it to be re-evaluated, or of course you can just source it)
• bash ignores ~/.profile if there is a ~/.bash_profile or ~/.bash_login (IIRC)

Submodules are for defining the type, so the only thing you get is interface (options), not implementation.

You do get a functional config in submodules… try this (it doesn’t do anything so you can just import into any configuration.nix):

{ config, lib, pkgs, modulesPath, specialArgs, options, ... }: {

  options.mynamespace = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule ({name, config, ...}:{
      options = {
        option1 = lib.mkOption { type = lib.types.str; default = ""; };
        option2 = lib.mkOption { type = lib.types.str; default = ""; };
      };
      config = {
        option2 = "derived from value of option1: '${config.option1}'";
      };
    }));
  };

  config = {

    mynamespace.submodule1.option1 = "value of option1";

    fileSystems = builtins.trace (builtins.toJSON config.mynamespace) {};

  };

}

Your module only defines the option inside types.submodule - I’d (ideally, to better organize the code) want to also put the config section in the submodule.

Ie. your code is structured similar to:

options = {
    fileSystems = mkOption {
    type = types.attrsOf (types.submodule {
        options = {
          # bla bla
        };           
    };
    };
};

config = {
  # set options here
};

while what I would like to do is more like

options = {
  fileSystems = mkOption {
    type = types.attrsOf (types.submodule {
      options = {
        # bla bla
      };
      config = {
        # set options here
      };
  };
};

The reason why I’m trying to do so is purely to restructure my code (which right now does has the config logic at the module, rather than submodule, level) in order to make it more readable/manageable, since it currently has jems like:

config.services.restic.backups = builtins.listToAttrs (
  builtins.concatLists (lib.attrsets.mapAttrsToList (v-name: v-cfg: (
    builtins.concatLists (lib.attrsets.mapAttrsToList (s-name: s-cfg: (
      builtins.concatLists (lib.attrsets.mapAttrsToList (r-name: r-cfg: (

I know I can restructure the code in other ways (eg. let .. in) - I just wanted to put the options definitions together with the code that uses them.

I figured that much :) I was wondering about the “best” (recommended? idiomatic?) way to get some decent/usable output instead of <code> or unformatted JSON (from builtins.toJSON).</code>

That was my first idea (well, I say “my”… but it was really suggested by yourself in the question I posted the other day), but it results in nixos complaining that error: A definition for option 'environment.systemPackages."[definition 1-entry 1]"' is not of type 'package'.

It might very well be that I’m doing some stupid mistake here (or maybe it’s something that used to work and doesn’t anymore?)… here’s what I used to test it out:

  environment.systemPackages = [
    pkgs.writeShellApplication {
      name = "some-script";
      text = "echo hello wolrd";
    }
  ];

Edit:

And indeed I was the one doing stupid things: it must be

  environment.systemPackages = [
    (pkgs.writeShellApplication {
      name = "some-script";
      text = "echo hello wolrd";
    })
  ];

with the parentheses, or it’s a list with two elements (a function and an attrset)…

If you just want to give the drvs names […], simply use a let binding.

I must be missing something here… my first idea was to put all the writeShellApplications inside systemPackages (with no let bindings: the scripts are generated from config anyway), but it resulted in nixos complaining that it was expecting actual packages.

Edit: scratch that - I was being stupid :)

Well, it does work as-is, and it’s not like I’m worried how many symlinks need to be dereerenced… the point is mainly that my nix code could be much simpler if I didn’t have to build the overlay attrset like that from a list.

Thanks: that helps a lot. I’m still quite confused about nixos concepts (and by the lingo too).

edit: Turns out you can’t just put writeShellApplicaiton { ... } in systemPackages directly: you need to add the package via an overlay (see https://discourse.nixos.org/t/referencing-the-output-of-writeshellapplication-as-a-package-in-another-nix-file/23363)

edit2: Actually, /u/hallettj@beehaw.org is 100% right: one can put writeShellApplicaiton { ... } inside systemPackages, but it must be systemPackages = [(writeShellApplicaiton { ... })] with the parentheses, otherwise writeShellApplicaiton is not applied to its argument and the two end up as two separate elements in the list.