| 27 Mar 2023 |
 infinisil | nbp: Regarding S.O.S., I think this is also something the working group needs to take into account and check whether it might be a better alternative. | 16:23:57 |
| infinisil | nbp: How sure are you that S.O.S. solves all of the problems described here? | 16:25:27 |
 Wanja Hentze | what's SOS short for? | 16:26:06 |
| infinisil | Oh and even if you don't have time to actually work with the WG, you can still contribute by just reviewing what the WG does | 16:26:27 |
| infinisil | Wanja Hentze: https://github.com/NixOS/rfcs/pull/3 | 16:26:35 |
 nbp | In reply to @infinisil:matrix.org
nbp: How sure are you that S.O.S. solves all of the problems described here?
- Overlays are outside the scope of S.O.S., overlays are how layers are applied one after the other.
- S.O.S. should help unify
override, .overrideAttrs, overrideDerivation, extendDerivation, .overrideScope', .extend, makeScope, .overridePythonAttrs, pkgs.haskell.lib.overrideCabal and probably more under a single update operator syntax.
- S.O.S. does not solve discoverability, as this is a problem which is orthogonal.
mkDerivation can be updated to have a fix set of inputs, which would make it nicer with or without S.O.S.
- S.O.S. does not solve the merging responsibility, but it provides update operator (or 2 functions in the mean time) to resolve this problem to be use as the base for any automated logic that we might want to add on top.
- S.O.S. does not require the evaluation on previous overriden packages in case of extension, as
mkDerivation would be called after the fix-point.
| 16:37:43 |
| infinisil | nbp: Then honestly S.O.S. doesn't sound like it would work as well as something like the module system | 16:45:35 |
| nbp | because this is not a module system, this is just a different way of ordering computation, which let you parametrize before computing, thus remove the need for unpeeling functions before adding them back (all our override functions today …) | 16:47:03 |
| nbp | * because this is not a module system, this is just a different way of ordering computation, which let you parametrize before computing, thus remove the need for unpeeling functions before adding them back (i.e: all our override functions today …) | 16:47:09 |
| nbp | And I honestly recommend adopting something like S.O.S. before trying to solve a larger problem of how the merging responsibility is handled. | 16:47:57 |
| nbp | Nickel provide a nice approach to having type-like per attribute, and merge definition per attribute, but this is something which can be added later on, after having a clean syntax which no longer requires override functions. | 16:49:19 |
| nbp | To summarize. Yes S.O.S. does not answer all the problems, it focuses on the override one, and does not prevent fixing the other problems later / sooner. | 16:51:13 |
| infinisil | If we want to consider doing SOS instead of a module system to solve these problem, then SOS needs to be at least better than the module system at solving these problems. | 16:51:45 |
| infinisil | Yeah I guess we don't need to solve all problems at once, but it would be nice, and it's what the module system seems to be able to do | 16:52:53 |
| infinisil | nbp: Wait in your proposal, can SOS be used outside of Nixpkgs by third-parties? Iirc it can't | 16:53:21 |
 toonn | The current "module" system? | 16:53:41 |
| infinisil | Oh I guess via overlays | 16:53:42 |
| infinisil | In reply to @toonn:matrix.org
The current "module" system? Not entirely sure what your question is :) | 16:54:19 |
| toonn | "and it's what the module system seems to be able to do" Are you referring to what is currently called "the module system," even though it has very little to do with what is generally considered a module system in other languages? Or did you mean "a module system" like before? | 16:56:44 |
| toonn | I just want to make sure I'm following the discussion. | 16:57:01 |
| infinisil | toonn: Oh yeah it's the current module system used for NixOS | 16:59:34 |
| nbp | In reply to @infinisil:matrix.org
nbp: Wait in your proposal, can SOS be used outside of Nixpkgs by third-parties? Iirc it can't Nixpkgs based on S.O.S. can be used by third-parties.
However, it only solve the overriding issues within the Nixpkgs fix-point, i.e. if you want to override Nixpkgs packages, you would either use an overlay to benefit from S.O.S., or use the old way. | 16:59:34 |
| nbp | In reply to @infinisil:matrix.org
If we want to consider doing SOS instead of a module system to solve these problem, then SOS needs to be at least better than the module system at solving these problems. A module system solves a different problem which is either the package configuration and/or the package setup. These problems are orthogonal to S.O.S., and should probably be evaluated separately. | 17:01:48 |
| infinisil | nbp: I see, I'll definitely take another look at SOS and I might bring it up in the working group. I added it in https://discourse.nixos.org/t/working-group-member-search-module-system-for-packages/26574#previous-work-3 | 17:03:59 |
| nbp | Thus this would not be instead, but in addition to. Unless you want a single module system for Nixpkgs, instead of having one for each package. The problem of having a single module system for the entire Nixpkgs is that you are seting up the ground for something Nixpkgs kind of deliberately avoided, which is the combinatorial complexity of configurations.
In any cases, such module system would be easier to add after S.O.S. | 17:04:20 |
| nbp | * Thus this would not be instead, but in addition to. Unless you want a single module system for Nixpkgs, instead of having one for each package. The problem of having a single module system for the entire Nixpkgs is that you are seting up the ground for something Nixpkgs kind of deliberately avoided, which is the complexity of configurations.
In any cases, such module system would be easier to add after S.O.S. | 17:06:04 |
| infinisil | nbp: I kind of see what you mean yeah, the module system (in its current form) doesn't seem to solve the problem very well | 17:11:40 |
| infinisil | * nbp: I kind of see what you mean yeah, the module system (in its current form) doesn't seem to solve the problem of configs very well | 17:11:51 |
| nbp | The Module System does not solve any constraints, nor configure anything. It only combine configurations.
What most people expect from package managers is to choose between conflicting versions, which Nixpkgs avoided so far, or these have been hard-coded using some of the override functions and multiple installs from Nix. | 17:17:08 |
| nbp | Solving constraints between packages configuration is the source of the complexity I had mentioned previously, behind having a single module system for all of Nixpkgs. | 17:18:31 |
