Rename IFD (import from derivation) to something more appropriate

[fricklerhandwerk]

Problem

It's not always import and not always from derivation

Proposal

We may want to do it rather sooner than later, as there will be more to change the longer we wait.

@roberth: evaluation-time build dependency
@fricklerhandwerk: the mechanism is "reading build outputs during evaluation"

Priorities

Add 👍 to issues you find important.

[roberth]

The new term should be easy to understand both in an evaluator context and in a scheduling context.

• scheduling context: E.g. in logs and in CI the context is "this had to be built before we could continue", whereas in an
• evaluator context: it's all about the actual data and where it came from (from a build / from an output).

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-06-05-nix-team-meeting-minutes-60/28933/1

[fricklerhandwerk]

@NobbZ had a proposal that seems to satisfy requirements and sounds concise enough: read from realisation (RFR)

[infinisil]

I proposed this in a previous docs team meeting: "Nested evaluation", and I think this is much easier to read and understand than "read from realisation"

[Ericson2314]

Isn't it nested building not evaluation?

Realization for evaluation, building for evaluation. I'm starting to like "for evaluation" a lot.

[NobbZ]

"Nested evaluation"

Isn't that quite easy to confuse with the experimental feature "recursive-nix"?

We are already in a situation where some poeple are using "recursive nix" as an umbrella term that includes IFD and the experimental feature recursive-nix. Adding yet another term to the mix, that sounds more like an umbrella/category to refer to different techniques that achieve a similar goal is probably counter productive.

It is not that I want to push my own suggestion, I just threw it in for brainstorming in the discourse and got far further with it than expected, it is much more that I'd like to see terms that are distinguishable enough to make clear we are talking about different things!

They do not need to be technically correct, they need to be understood. Thats why I still consider "IFD"/"Import from derivation" as the ideal thing. We use it like that for many years, and it is well understood, there are a lot of third party ressources out there that already refer to it by that term. Renaming it just creates confusion.

[infinisil]

"Nested evaluation"

Isn't that quite easy to confuse with the experimental feature "recursive-nix"?

Good point. These features are actually similar, I wonder if it could make sense to think of them as the same core idea and use terms for that convey that. (Recursive Nix is a good name, but we shouldn't hold back from renaming it if necessary, since it's still an experimental feature).

Thats why I still consider "IFD"/"Import from derivation" as the ideal thing.

Renaming creates confusion for pre-existing knowledge and resources, but makes things easier to understand for everybody in the future. And with Nix continuing its growth, the fraction of the former becomes less and less, which makes me think it could be worth the trouble.

[infinisil]

Thinking about this again, we can call both "Recursive Nix", but to distinguish we can use:

• Eval-time recursive Nix (current IFD): Does a nested build/eval cycle during evaluation
• Build-time recursive Nix (current recursive-nix): Does an extra eval/build cycle during building

@NixOS/nix-team Can you confirm whether it would make sense to have this naming?

[thufschmitt]

https://github.com/orgs/NixOS/teams/nix-team Can you confirm whether it would make sense to have this naming?

There's indeed a symmetry between IFD and recursive-Nix, but calling them nearly the same feels quite confusing. I'd rather have some frankly orthogonal namings