The following sections describe the agenda of the meeting and also serve as a place to put the corresponding meeting notes. After the meeting, these notes are moved to https://github.com/nixpkgs-architecture/meetings. This HedgeDoc link will be reused for all subsequent meetings.
- Matrix announcement: https://matrix.to/#/!djTaTBQyWEPRQxrPTb:nixos.org/$48TUhZxhJxTWHcajZDd8aFn9DtjF2Lk9OHStsHERVEM
- Recording link: https://www.youtube.com/watch?v=WC-Dd1YSRxA
- Who records: @infinisil
- Who takes meeting notes: @roberth
- Who leads the meeting: @infinisil
- Member updates
- @mkaito application no updates
- @JohnEricson? no updates
No updates
- @profpatsch/@roberth: Basic mudule system replacement with better performance for packages.
- @mkaito: Eelco suggested a Nix-based module system
- @roberth: Somewhat close to the one from Eelco, but simpler, more documented. Should it be integrated? Conflicted, bad for compatibility, won't be able to use from older Nix. First have a prototype with all functionality, only when happy incorporate similar functionality into Nix
- @john: Move library code into builtins. But we shouldn't get stuck with a bad builtin design. Should have a decision, either libraries or builtins but stable.
- Nickel is more suitable for experimentation, thouhgh.
- @ash: What about a separate pure library repo for redesigning it
- @mkaito: Ran into this before
- @roberth: Concerned about fragmentation. Some value from refactoring but not fundamental
- @ash: Flakes to split lib into other repo
- @roberth: Already automated by someone?
- @infinisil: Possibility is adding existing lib functions to the builtins
- @mkaito: What are issues with the module system?
- @infinisil: 1 Performance, 2 not very clean because of legacy things. Needs to be tidied up before hardcoding it in Nix.
- @ash: Hardcoding it does not solve the architectural issues. Be careful about changing the language. Performance work may already be underway (?) so not a priority for us now
- @gytis: Let's ignore the Nix language side of this
- @mkaito: [Hints at RFC 22]
- @ash: discuss a summary of the previous meeting?
- @mkaito: have an agenda
Summary of previous meeting
-
better phases abstraction. Merge language logic into setup.sh/hooks
-
Gytis used the module system to replace mkDerivation (at Nixlang level)
- use module system instead of hooks?
- @DavHau: use it to unify the Nix-level things and setup.sh-level things
- @DavHau: dream2nix uses module system for some configuration, planned for packaging. Wants to see module system / minimod develop, concerned about lost effort in dream2nix
-
@Gytis: let's present solutions/progress next meeting?
- bash is still a problem, because especially build input handling is very hard to understand
- @infinisil: presenting is ok; still something we can discuss
- @DavHau: define phase as a process with a specified interface; no need to specify language
- @Alex Ameen: how do these processes interact?
- @ash: wasn't language discussion out of scope?
- @infinisil: agreed.
- @ash: separate matrix channel for topic?
- @Gytis: gradual or sudden change?
- @infinisil: gradual, @roberth agrees
- @John: what process do we want for our changes?
- @mkaito: but we do have to keep our goals in mind
- @Gytis: homework: we need to decide gradual / rip-off bandaid
- @Gytis/@John: this PR simplifies stdenv NixOS/nixpkgs#132343
- @John: this stuff requires long focused work and learning, not multitasking
- @Gytis: bootstrapping can be improved, inspired by guix
- @infinisil: we want to make C/C++ a plugin of a the generic setup.sh
- @John: removing build input abstraction may simplify the writing of language integrations
- @Alex Ameen: m4 regeneration is causing headaches. Keep me in the loop. Number of gcc-related patches is scary
-
@Gytis: Main issues:
- Complex bootstrap and dependency trees (PR 132343 is a gateway to clean this all up)
- Complexity of our bash magic. It needs to be rewritten in an understandable mannner (New language is required)
- @John: Yeah we can do less in bash, until bash becomes trivial to replace
- @John: On the other hand. "oil and bash" I don't think has been adiquately discussed :)
- Help @JohnEricson with NixOS/nixpkgs#132343
- Reaching contentious on upgrade apprach. Are we ripping bandaid off or is it supposed to be a gradual change (bash compatible or not?)
- It would be super useful to have summary of how Guix does things. Is anyone up to take this as a homework?