In reply to @nbp:mozilla.org
Almost the same story for SOS, the intent was to not remove mkDerivation but delay it to be executed at the very end of the fix-point, thus making packages just ordinary attribute sets available through prev/super, which can be overwritten by using Nix's update operator within Nixpkgs' overlays.

by flattening python packages under the top-level fix-point. What these python sets are is a custom python package with a set of python packages relying on these.

To make it short, this is providing only a different scope from which packages are taken from. I opened a PR on this topic a while ago. https://github.com/NixOS/nixpkgs/pull/44196

An alternative would be to make inherited inputs. For example:

{
  python99Packages = {
    __scope = { buildInputs = { python = …; }; }
  };
}

In which case one could assume that the last scope definition overrides the package inputs, unless override by the user with the update operator.

We have many options to choose from.

Cue suffers from the same slowness problems as the nixos module system afaik

On the performance matter, it's not really related to modules per se but in general I personally have high hopes in the incremental evaluation approach. It's less of an issue that your evaluation from scratch is slow, under the hypothesis that each new generation is just a small diff from the previous one, and that your interpreter can reuse most of the previous results incrementally. Lazy evaluation turns out to play quite well with incremental evaluation (basically, you can more or less swap the evaluator with a one performing various caching strategies without changing the semantics of the language). But hard to tell before trying this at scale.

The problem is unscoped merging, aka if you want to figure out whether something exists, you have to potentially search through every module definition

I might be misunderstanding, but I feel like it's more of a NixOS module system design decision (put everything in one big fixpoint soup), rather than something inherent to merging as defined e.g. in CUE ? Couldn't you build a more scoped/hierarchical system based on CUE for example (or even in pure Nix)?

In reply to @yannham:matrix.org
CUE is a configuration language, non Turing-complete, with a very interesting approach (https://cuelang.org/). I would suspect it's not expressive enough for the Nix use-case, but they have a "meet" operator that is close to the fixpoint-merging done by the NixOS module system and Nickel's merging (and, for that matter, Jsonnet's inheritance '+' operator)