| 14 Nov 2023 |
| NixOS Moderation Bot banned @srid:matrix.org (<no reason supplied>). | 14:00:49 |
| 15 Nov 2023 |
| @grahamc:nixos.orgchanged room power levels. | 16:15:41 |
| @grahamc:nixos.org left the room. | 16:15:42 |
@willpower3309:matrix.org | In reply to @infinisil:matrix.org piegames: No concrete proposals yet, and I'm not working on it myself Is anyone taking a look at nix modules? I recall a modules workgroup was made, but it seems it may have been merged with the architecture group | 16:48:05 |
infinisil | willmckinnon: DavHau has looked a bit into it recently | 16:49:30 |
DavHau | I did experiments on nix-camp. I will open a WIP PR to make it visible. RN I'm a bit busy with other stuff. | 16:56:57 |
Ilan Joselevich (Kranzes) | (Dave showed me at oceansprint how he made mkDerivation use evalModules in nixpkgs, it's sick 🔥) | 16:59:28 |
DavHau | It trades significantly better UX vs twice the eval time. Maybe it could be released as an overlay for people who don't care much about eval time. direnv recently got a feature where it caches evaluation indefinitely until 'nix-direnv-reload' is executed manually. The way slow eval times are a lot less annoying than before. | 17:23:27 |
DavHau | * It trades significantly better UX vs twice the eval time. Maybe it could be released as an overlay for people who don't care much about eval time. direnv recently got a feature where it caches evaluation indefinitely until 'nix-direnv-reload' is executed manually. That way slow eval times are a lot less annoying than before. | 17:23:53 |
| Alyssa Ross | 17:40:09 |
| NixOS Moderation Botchanged room power levels. | 18:12:25 |
| NixOS Moderation Botchanged room power levels. | 18:12:25 |
| @eisfunke:eisfunke.com changed their profile picture. | 22:42:08 |
| 18 Nov 2023 |
infinisil | Highlighting @abathur's issue: https://github.com/nixpkgs-architecture/issues/issues/23 | 04:07:31 |
| 19 Nov 2023 |
| pbsds changed their display name from pbsds to pbsds (federation borken, may not see reply). | 03:36:21 |
| ZXGU joined the room. | 11:02:45 |
| pbsds changed their display name from pbsds (federation borken, may not see reply) to pbsds. | 20:39:20 |
| 20 Nov 2023 |
@johannes.kirschbauer:scs.ems.host | In reply to @piegames:matrix.org Are there any specific proposals for how a Nix module builtin might look like? Playing mindgames:
If types are values. We could extend the language by type-values. e.g.
Primitives:
Number, ... Composed:
Set, List, ...
{
/* A type contract, foo must be a number*/
foo = Number;
} &
{
/* foo is '1' */
foo = 1;
}
{}
| 10:03:41 |
@johannes.kirschbauer:scs.ems.host | In reply to @piegames:matrix.org Are there any specific proposals for how a Nix module builtin might look like? * Playing mindgames:
If types are values. We could extend the language by type-values. e.g.
Primitives:
Number, ... Composed:
Set, List, ...
{
/* A type contract, foo must be a number*/
foo = Number;
} &
{
/* foo is '1' */
foo = 1;
}
Introducing new keywords for types ^^
| 10:04:04 |
@johannes.kirschbauer:scs.ems.host | * Playing mindgames:
If types are values. We could extend the language by type-values. e.g.
Primitives:
Number, ... Composed:
Set, List, ...
{
/* A type contract, foo must be a number*/
foo = Number;
} &
{
/* foo is '1' */
foo = 1;
}
Introducing new keywords for types ^^ and the merge operator &
| 10:04:22 |
@piegames:matrix.org | So basically copying over Nickel :) | 10:04:51 |
@johannes.kirschbauer:scs.ems.host | Yes, why not. | 10:06:00 |
@johannes.kirschbauer:scs.ems.host | It resolves the need for our overly complex module system. With a ton of different merge operations | 10:06:59 |
@piegames:matrix.org | I don't disagree | 10:07:19 |
@johannes.kirschbauer:scs.ems.host | 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.
| 10:14:15 |
@johannes.kirschbauer:scs.ems.host | * 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.
| 10:14:51 |
@johannes.kirschbauer:scs.ems.host | * 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.
| 10:15:03 |
@johannes.kirschbauer:scs.ems.host | Hm nickel is still different i think. | 10:21:05 |
| 21 Nov 2023 |
| Eelco changed their display name from niksnut to Eelco. | 16:36:55 |
| 24 Nov 2023 |
@yannham:matrix.org | 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`
[...]
| 09:27:24 |