Can/should options share a "namespace"?

[shanesveller]

I am working on a reusable library-style flake for managing BEAM (Elixir/Erlang) applications using flakes + flake-parts, and want to expose some configuration knobs around the conventions I have in mind.

Some of the configuration settings I have imagined make sense to be a top-level option (not perSystem), and some make more sense as perSystem instead.

Is it nonsensical for me to want to structure the consuming side like so?

    flake-parts.lib.mkFlake {inherit self;} {
      imports = [myFlake.flakeModule];

      systems = ["aarch64-darwin" "x86_64-darwin" "x86_64-linux"];

      beamWorkspace = {
        # system-agnostic details
        versions = {
          elixir = "1.14.2-otp-25";
          erlang = "25.1.2";
        };
      };

      perSystem = {pkgs, ...}: {
        beamWorkspace = {
          # concerns that are either conditional on system or
          # necessarily system-specific as an implementation detail
          enable = true;
          devShell.languageServers.elixir = true;
          devShell.languageServers.erlang = false;
          devShell.extraPackages = [pkgs.hello];
        };
      };
    };

Will this mindset cause me technical problems on the implementation side? As a specific example, will the current mechanics permit me to have config.beamWorkspace mingle both top-level options and perSystem options? So far I've stumbled a few times and I'm wondering if I'm holding it wrong or if the design is in some way unsuitable.

[roberth]

Is it nonsensical for me to want to structure the consuming side like so?

Certainly not nonsensical, but I'm currently leaning towards using perSystem for everything, except things that are truly global, like nixosConfigurations. The reason is that it's less confusing to have things in one place, because some configuration - package choices - will be inherently system-dependent.
Top level configuration can represent system-dependent by changing the types to be a function that take system, but this is a pain to configure. E.g.

{ withSystem, ... }: {
  options.foo.package = mkOption {
    type = types.functionTo types.package;
  };
  config.foo.package = system: withSystem system ({ config, ... }: config.packages.foo);
}

Arguably this is exactly like putting the option in perSystem, but with a worse UX.

        versions = {
          elixir = "1.14.2-otp-25";
          erlang = "25.1.2";
        };

What if there's an issue with erlang on one system? It would have to become conditional, but that's basically impossible to achieve now because it's top level.

for managing BEAM (Elixir/Erlang) applications

Awesome :)

Would you like it to be listed on https://flake.parts?

[shanesveller]

What if there's an issue with erlang on one system? It would have to become conditional, but that's basically impossible to achieve now because it's top level.

That one's not even a hypothetical, heh. The current logic I have is meant to be a bridge from https://github.com/asdf-vm/asdf-erlang and https://github.com/asdf-vm/asdf-elixir, which IME are widely used in the BEAM community. (Note how many system-level deps the former needs!)

My library flake is meant to parse the version nomenclature used by those projects, or optionally directly parse their .tool-versions file from the consuming repository, to ease adoption. It also helps preserve interop for contributors to projects who don't use or plan to use Nix. For anyone still curious, it's something I'm working on in public at https://github.com/shanesveller/nix-beam-flakes.

Would you like it to be listed on https://flake.parts/?

That would be awesome in the future, but I don't feel the current code is ready for many eyes or users just yet. I see Srid's Haskell work on there, which poses some inspiration for me, as does the UX of oxalica/rust-overlay.

[shanesveller]

I am starting my documentation pass now: https://github.com/shanesveller/nix-beam-flakes#1