Two misc ideas for Nix itself

[Ericson2314]

CC @roberth

[Janik-Haag]

Can you add a descriptions in a similar manner to #14 and summarize the current state of the issues?

[Ericson2314]

OK added descriptions

[Janik-Haag]

Should I still wait with merging until roberth gave it a look?

[Ericson2314]

I'll try to get another Nix team person to weigh in

[roberth]

another Nix team person

I kinda already started typing. Did you mean someone other me? That would be good.
Nonetheless here are my thoughts:

CLI stabilization

Might CLI stabilization be a better choice? It'd be good to finish ongoing projects first, but then we might underestimate the effect on consistency from having done CLI review together. We have guidelines, but those are probably not sufficient. I wonder how much can be done without requiring an equal amount of input from team members.

Thoughts about changing the data model

We should organize those issues into an epic or tracking issue, along with

• Make output paths/hashes indifferent to possible CA/FOD origin of sources nix#9259

and (just for context) perhaps even

• WIP vision for builders data model (build capabilities) nix#9899 (e.g. build capability requirements should be hashed, but build scheduling hints should not)
• Redefine outputs in terms of language-level "package", not necessarily store-level derivation (RFC-92, and multi-drv packages, docs) nix#6507 (vaguely related to the derivation primop)

Our ecosystem-wide data model is slightly off in many places. I think this strategy is generally applicable

• refactor internal Nix data structures (without change in behavior)
• expose simplified logic based on the improved internal data model, masked by experimental feature

I'm conflicted about the size and scope of such feature flags. We have multiple fixes, and by balling them together we may avoid some unnecessary compatibility logic, which we'd have to support indefinitely. But also it risks creating a dragged out change process as with Flakes.

[fricklerhandwerk]

Sounds reasonable for beginners with some C++ knowledge.

[Ericson2314]

@roberth I meant you, or baring that, someone else. I.e. not me alone. Not excluding you :).

[Ericson2314]

Yeah re @roberth the ideal thing would be some epics, and the GSOC person can simple start on what bite-sized pieces are not done by the time summer rolls around, but sadly I think grant processes punish agility like that.

[Janik-Haag]

Is there anything missing here or can I go ahead and merge this?

[Ericson2314]

@Janik-Haag Yeah it can be merged. @roberth and I agree the stuff he wrote is not for changing it, but for following this up with more ideas if we like.