let 
  partialFoo = {
  nested = {
     foo = Number:
  };
}
in
 partialFoo & {
  nested.foo = 1;
}

You can even use that value as type contract in any other place. e.g. if you want to say that bar is also of type foo.

{
  bar = partialFoo & {
   nested.foo = 2; 
  }
}

I kind of like the simplicity.

let 
  partialFoo = {
    nested = {
      foo = Number:
    };
}
in
  partialFoo & {
    nested.foo = 1;
  }

You can even use that value as type contract in any other place. e.g. if you want to say that bar is also of type foo.

{
  bar = partialFoo & {
   nested.foo = 2; 
  }
}

I kind of like the simplicity.

let 
  partialFoo = {
    nested = {
      foo = Number:
    };
  };
in
  partialFoo & {
    nested.foo = 1;
  }

You can even use that value as type contract in any other place. e.g. if you want to say that bar is also of type foo.

{
  bar = partialFoo & {
   nested.foo = 2; 
  }
}

I kind of like the simplicity.

FWIW, In Nickel, currently you can't merge a contract and a number directlylike Number & 1 (maybe it would make sense to do that, but at least for now, we don't). However, because record contracts are no different from normal records (they are just more likely to have mostly annotations and yet-to-be-defined values), there is in theory two ways to "apply" a record contract. One is by setting the contract using =, as in Johannes Kirschbauer @hsjobeki 's example above:

let Contract = { foo | Number } in
{
  inner = Contract
} & {
  inner.foo = 1
}

Merge will be applied recursively and combine {bar = 1} with {bar | Number} and end up checking that 1 is a Number. However, usually what you want is to use an annotation/metadata (|) instead:

{
  inner | Contract
} & {
  inner.foo = 1
}

The difference is that the second form is more restrictive: it says "attach a contract Contract to inner". Attaching a contract propagates through merging, even if you override. That is, it means inner can never be changed or updated by merging to something that doesn't respect the initial contract. In particular, the contract is closed by default, meaning you can't add new values (for that, you have to add an ..), while solely merging records propagate the subcontracts but you can always merge with new stuff. Attaching a contract is thus more similar to the CUE model, it "refines" a value with a constraint, and merging just refines more and more.

For example:

nickel> { inner = Contract } & { inner.foo = 1} & {inner.bar = "hello"}
{ inner = { bar = "hello", foo | Number = 1, }, }

# turning the `=` into `|` makes it stricter
nickel> { inner | Contract } & { inner.foo = 1} & {inner.bar = "hello"}
error: contract broken by the value of `inner`: extra field `bar`
[...]

# With `=`, we can override the whole contract
nickel> { inner = Contract } & { inner | force = "something totally different"}
{ inner | force = "something totally different", }

# `|` doesn't let you do that
nickel> {inner | Contract} & { inner | force  = "something totally different"}
error: contract broken by the value of `inner`
[...]

FWIW, In Nickel, currently you can't merge a contract and a number directlylike Number & 1 (maybe it would make sense to do that, but at least for now, we don't). However, because record contracts are no different from normal records (they are just more likely to have mostly annotations and yet-to-be-defined values), there is in theory two ways to "apply" a record contract. One is by setting the contract using =, as in Johannes Kirschbauer @hsjobeki 's example above:

let Contract = { foo | Number } in
{
  inner = Contract
} & {
  inner.foo = 1
}

Merge will be applied recursively and combine {foo = 1} with {foo | Number} and end up checking that 1 is a Number. However, usually what you want is to use an annotation/metadata (|) instead:

{
  inner | Contract
} & {
  inner.foo = 1
}

The difference is that the second form is more restrictive: it says "attach a contract Contract to inner". Attaching a contract propagates through merging, even if you override. That is, it means inner can never be changed or updated by merging to something that doesn't respect the initial contract. In particular, the contract is closed by default, meaning you can't add new values (for that, you have to add an ..), while solely merging records propagate the subcontracts but you can always merge with new stuff. Attaching a contract is thus more similar to the CUE model, it "refines" a value with a constraint, and merging just refines more and more.

For example:

nickel> { inner = Contract } & { inner.foo = 1} & {inner.bar = "hello"}
{ inner = { bar = "hello", foo | Number = 1, }, }

# turning the `=` into `|` makes it stricter
nickel> { inner | Contract } & { inner.foo = 1} & {inner.bar = "hello"}
error: contract broken by the value of `inner`: extra field `bar`
[...]

# With `=`, we can override the whole contract
nickel> { inner = Contract } & { inner | force = "something totally different"}
{ inner | force = "something totally different", }

# `|` doesn't let you do that
nickel> {inner | Contract} & { inner | force  = "something totally different"}
error: contract broken by the value of `inner`
[...]

FWIW, In Nickel, currently you can't merge a contract and a number directlylike Number & 1 (maybe it would make sense to do that, but at least for now, we don't). However, because record contracts are no different from normal records (they are just more likely to have mostly annotations and yet-to-be-defined values), there are in theory two ways to "apply" a record contract. One is by setting the contract using =, as in Johannes Kirschbauer @hsjobeki 's example above:

let Contract = { foo | Number } in
{
  inner = Contract
} & {
  inner.foo = 1
}

Merge will be applied recursively and combine {foo = 1} with {foo | Number} and end up checking that 1 is a Number. However, usually what you want is to use an annotation/metadata (|) instead:

{
  inner | Contract
} & {
  inner.foo = 1
}

The difference is that the second form is more restrictive: it says "attach a contract Contract to inner". Attaching a contract propagates through merging, even if you override. That is, it means inner can never be changed or updated by merging to something that doesn't respect the initial contract. In particular, the contract is closed by default, meaning you can't add new values (for that, you have to add an ..), while solely merging records propagate the subcontracts but you can always merge with new stuff. Attaching a contract is thus more similar to the CUE model, it "refines" a value with a constraint, and merging just refines more and more.

For example:

nickel> { inner = Contract } & { inner.foo = 1} & {inner.bar = "hello"}
{ inner = { bar = "hello", foo | Number = 1, }, }

# turning the `=` into `|` makes it stricter
nickel> { inner | Contract } & { inner.foo = 1} & {inner.bar = "hello"}
error: contract broken by the value of `inner`: extra field `bar`
[...]

# With `=`, we can override the whole contract
nickel> { inner = Contract } & { inner | force = "something totally different"}
{ inner | force = "something totally different", }

# `|` doesn't let you do that
nickel> {inner | Contract} & { inner | force  = "something totally different"}
error: contract broken by the value of `inner`
[...]

Here is the reason why I think a module system (not only "the" module system) is not suited for the top-level for Nixpkgs, as opposed to using it for the configuration of packages.

A module system is about squashing additional non-conflicting changes and makes an exception for ordering with mkOrder, where as the override logic is all about ordering when changes are applied, when packages / package-set are copied under a different name and mutated separately it in a different way and replace the logic that previously existed.

To make it work, one would have to add extra semantic, such as the order of modules, to inject a default ordering / priorities into a module system used in the context of Nixpkgs. Thus, the modules would no longer be position independent.