Allow auto-calling installables.

[shlevy]

This allows for installable-based interfaces to allow for dynamic configuration at the command line. See e.g.
Gabriella439/terraform-nixos-ng#6 for one use case.

Checklist for maintainers

Maintainers: tick if completed or explain if not relevant

• agreed on idea
• agreed on implementation strategy
• tests, as appropriate
  • functional tests - tests/**.sh
  • unit tests - src/*/tests
  • integration tests - tests/nixos/*
• documentation in the manual
• documentation in the internal API docs
• code and comments are self-explanatory
• commit message explains why the change was made
• new feature or incompatible change: updated release notes

Priorities

Add 👍 to pull requests you find important.

[roberth]

I really don't like that this makes a change to the schema expected by other flake code. someFlake.packages.foo could be "anything" now.

There's also an argument to be made that configuration outside the flake should be avoided, although taking information from the outside should be possible by choice. However, I don't think we should morph the existing well defined attributes to accomodate this, but rather lean into the fact that they're not "pinned down" packages (or whatever the thing is your pulling from the flake).

Finally we may consider configurability that applies to the whole flake instead of just an attribute; effectively extra inputs, but the same caution about "pinning down" or some more vague idea about reproducibility applies.

[roberth]

What if we made it easier to write a proper call on the command line?
That way we can stop hardcoding ad hoc conventions in Nix and use the power of the language instead.

[shlevy]

I really don't like that this makes a change to the schema expected by other flake code. someFlake.packages.foo could be "anything" now.

No, it doesn't. This gives Nix the ability to autocall, it doesn't impact whatever conventions or standards we have for what types are expected at which output attributes. If we want to, we can establish separately (through docs, nix flake check, etc.) that packages is still for packages and configurablePackages is for something else.

There's also an argument to be made that configuration outside the flake should be avoided

Yes, but it's ultimately wrong. There are plenty of real important use cases where one cannot up front determine exactly how some code is going to be used. The current workaround is to create a new flake, which in addition to being technically inconvenient is not semantically correct: I do not want to create a new consumable Nix package (in the PL sense), I want to consume another Nix package in the way appropriate to my usage.

Finally we may consider configurability that applies to the whole flake instead of just an attribute

We should think of flakes as being the analogue of a package in another programming language, exposing various values in that language. Let's look at Haskell packages and see what the analogy can tell us: There is both whole-package configurability (cabal flags) and individual exposed element configurability (runtime arguments to functions). The former is about compile time, how the whole package is built and packaged. The latter is about use time. So even if we do want flake-wide configurability (and I'd like to see a use case) it won't fit what we're trying to do here.

What if we made it easier to write a proper call on the command line?

This is one possibility I considered. I think it would amount to either an --arg-flake flag (so one could write nix build -E '{ glibc }: glibc.dev' --arg-flake glibc nixpkgs#glibc) or an --expr-flake flag (so one could write nix build --expr-flake '{ outputs = { nixpkgs }: packages.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.glibc.dev; }'). I would be open to creating that PR as well.

That way we can stop hardcoding ad hoc conventions in Nix

As I said above, this PR does not hard code nor change any flake conventions.

[edolstra]

So far, we've resisted adding the ability to pass arguments to flakes, since 1) they're not discoverable; 2) they break the requirement that flakes "just work", i.e. they will cause people to write flakes that require the user to pass in a bunch of undiscoverable options via the command line.

See #6583 for an attempt to address the discoverability issue.

[shlevy]

OK, #6583 is a better way to deal with this. Closing