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/$dkSDPpbzHyDgf_8yydZQTS7M0YMt3WGjxptvkcjD6-E
- Recording link: https://www.youtube.com/watch?v=9W-gA9ccS9g
- Who records: @infinisil
- Who takes meeting notes: @infinisil
- Who leads the meeting: @infinisil
- Finding a new time for the meeting
- @infinisil: Auto-called package listing
- @ash: Many PR's blocked from merging due to all-packages.nix merge conflicts
- @infinisil: Any opposition?
- @ash: Performance concerns, GitHub file count limit
- @j-k: all-packages.nix display limit
- @infinisil: hello lives in pkgs/he/hello, good?
- @ash: Looks fine. adisbladis experimented with basic flattening, performance improved by two times, not sure if that's nested or not.
- @infinisil: Lots of
lib's -> not limited to prefix of two, could be arbitrary- @ash: Prefix for lib -> where does libreoffice go? Edge cases
- @robert: Not use prefix at all, simple, use file search feature
- @j-k: Re lib, was some discussion in matrix. Problem with one folder and find feature -> can't scroll.
- @ash: Never manually gone to file on github, too difficult to find.
- @infinisil: I use it sometimes
- @j-k: Change depth where packages live -> need to fix relative references. Unrelated: Mixture between update scripts doing ./., or where the script lives.
- @ash: Mix of update scripts, direct update or create file in /tmp
- @ash: Other issue: Rearchitecting renders every PR conflicting, choose branch-off point, work with people doing formatting
- @robert: Can be a gradual change,
- @infinisil: Enforce new and updated packages to use new structure
- @ash: Not a lot of bandwidth
- @infinisil: If we can automate it, do it
- @ash: Work with formatting, similar changes. Bring up in RFC 101
- @ash: What do we do about package sets?
- @infinisil: Don't touch it
- @alex: Agreed
- @infinisil: Don't touch it
- @infinisil: Allow files, e.g. pkgs/hello.nix?
- @ash: No need to, more inconsistent
- @j-k: Maybe very simple initially, but when you need another file lots of changes
- @ash: How to deal with arguments? all-packages.nix only with overlays for packages that need it
- @alex: That's what I did
- @infinisil: Get rid of them when possible
- @alex: setFunctionArgs in callPackage, leave it in function state before evaluating
- @infinisil: overrides.nix file with e.g.
hello = { glibc = null; }
- @infinisil: @alex, take the stage
- @alex: Took a lot of node packages at work and made them work better. There's a lot of conflicting package versions in node, contrary to nixpkgs (which I think is better). How to manage and refer to multiple versions. Tried
groupBywith name and version, nested -> overlays complicated. Another attempt adding/between name and version, as a reserved character,"${pname}/${version}", latest version islatest. Another attempt: using two-to separate. In nixpkgs at least consistent suffixes would be great, various ways of doing things. In nixpkgs there's more control over package names. Tricky: If a user wants to define an override for e.g. 8 versions, it's hard to specify override for all versions.- @ash: I like the
/idea- @alex: At first not a fan of it because it needs quoting in shell.
- @ash: I can see it working well with auto-calling packages
- @alex: To pin a package just add version specifier at the end.w
- @alex: Easy to split by
/ - @infinisil: With auto-calling,
/would correspond to a subdirectory - @ash: Needs good discovery, not any random file should be called
- @ash: I like the
- @infinisil: Feature sets, select major version only,
pkgs.hello.version "with-gui"- @alex: Thought about this, had to deal with it. Had to deal with sem ver conditionals. If you really need a specific version an assert is great.
- @ash: Multi-version packages could become a nixpkgs primitive, providing additional attrs providing consistency. Extend to multiple flavours of packages,
ffmpeg,ffmpeg_full. Could beffmpeg.version.full- @alex: Context in nixpkgs?
- @infinisil:
- @ash: wine inconsistencies in aliasing
- @alex: Aliasing at the end, just for being able to reference them. Easily creates duplicates with multiple id
- @infinisil: Aliases should be disallowed from overriding in nixpkgs? Somewhat doesn't work
- @ash: Common pattern in multi-version packages:
common.nixcalled multiple times internally by specific versions. Problem:common.nixis often not exposed, can't modify parts of it. If we invert it,common.nixhaving passthru, overrides could affectcommon.nixand all the versions it specifies.- @infinisil: Passthru with a builder for the package.
- @alex: Baseline, but always swap out source
- @infinisil: Relates to package builders and phases
- @infinisil: @alex:
groupBycan work? Needs overriding improvement- @alex: Can work. Would be cleaner for top-level organization. Have a type for package sets.
- @infinisil: recurseIntoAttrs is similar
- @alex: Aliases should be kept out of the mix. Mapping function over package set needs to not use all entries, e.g. aliases not
- @alex: Can work. Would be cleaner for top-level organization. Have a type for package sets.
- @alex: Took a lot of node packages at work and made them work better. There's a lot of conflicting package versions in node, contrary to nixpkgs (which I think is better). How to manage and refer to multiple versions. Tried
- @robert: https://nixos.org/manual/nixpkgs/stable/#sec-package-naming
- @jtojnar: How to deal with overriden instances, e.g.
webkitgtk_4_1 = webkitgtk.override {libsoup = libsoup_3; }; - @alex: Example
pkgs = {
foo = pkgs."foo/3.0.0";
"foo/1.0.0" = ...;
"foo/2.0.0" = ...;
"foo/3.0.0" = ...;
} in pkgs
- @jtojnar: Is is possible to inject those though? quotes do not seem to work
({ "foo/1.0" }: …) { "foo/1.0" = …; }