Nixpkgs Architecture Team Meeting #19
- Past meeting notes
- Recording
- Matrix announcement
- Recorded by: @infinisil
- Lead by: @infinisil
- Meeting notes by: @growpotkin
- Present members: @infinisil @growpotkin @roberth @Ericson2314
Notes
Issues
Simple Package Paths
-
@infinisil created PR associated with sharding directory names.
- https://github.com/nixpkgs-architecture/simple-package-paths/pull/20
- Collected stats on how many packages fall into each substring category.
- Plan to use
builtins.substring 0 4 <attribute>to create shard-directory. - Compatibility Layer
- Emits warning for legacy style package names.
- Should we use symlinks for legacy support?
- @roberth okay with ignoring support for it
- @blaggacao if you build it, they will come, if you allow legacy names with symlinks people will depend on that.
- We don’t need it!
- @infinisil: +1
- @Ericson2314: +1
- @growpotkin +1
- @roberth: +1
Is the tree an API?
-
There’s
pkgs.pathnixpkgs pkgs = import nixpkgs {} pkgs.path == nixpkgsProbably an anti-pattern, doesn’t work as expected with overlays, config
-
There’s
meta.position→ for debugging and tooling -
modulesPath→ NixOS module specific, but definitely part of the API, should have symlinks when/if we change those
numbers.nix
- @infinisil created a utility for collecting statistics about shard-directory members/tree: https://github.com/nixpkgs-architecture/simple-package-paths/pull/21
pkgs/unit/hell/hello/unstructured/test.nix
https://github.com/nixpkgs-architecture/simple-package-paths/issues/19
- Protected namespace for misc files associated with a package.
- Makes existing files with common names distinct from new “standardized” filenames.
- Example:
test.nixmight exist in a package today, but may not follow standardized structure for “new”pkgs/unit/<SHARD>/<PNAME>/test.nixchecks.- NOTE: I have no idea if
test.nixis a prospective “standardized” file, I’m just providing an example.
- NOTE: I have no idea if
-
@roberth: Since for now we only have packages, let’s use a
pkgsubdirectory for all extra package-related files- @infinisil: +1
-
@growpotkin: Spell out
packageto avoid annoying completion?-
@infinisil: pkg/fun.nix instead of pkg-fun.nix?
-
@roberth: Right direction. Goes into removing initial
pkgsnesting, but we agreed to not do that
-
@roberth: Right direction. Goes into removing initial
- pfunk.nix???
-
@infinisil: pkg/fun.nix instead of pkg-fun.nix?
- @roberth: (implicit +1)
- @Ericson2314: Missing default.nix a bit, who uses which subdirectory?
- @roberth: pkg-fun/pkg-fun.nix?
- @infinisil: Does it make sense to have a single file to import all dirs? I don’t think so
- Example:
Proposals:
-
pkgs/unit/gnum/gnumake
- pkg-fun
- pkg-fun.nix
- foo.patch (imported by pkg-fun.nix)
- test.nix (imported by pkg-fun.nix)
- pkg-fun
-
pkgs/unit/gnum/gnumake
- pkg-fun.nix
- pkg
- foo.patch (imported by …/pkg-fun.nix)
- test.nix (imported by …/pkg-fun.nix)
-
@Ericson2314: defer more conventions for later, incubate in nixpkgs, before making it a more standardized convention
-
pkgs/unit/gnum/gnumake (
-
pkg-fun.nix
-
foo.patch (imported by pkg-fun.nix)
-
test.nix (imported by pkg-fun.nix)
-
@growpotkin: +1
-
@roberth: +1
-
@Ericson2314: +1
-
@infinisil: +1
-
-
@infinisil: In the future, add versioning:
-
pkgs/unit/gnum/gnumake
- .unit-version → Should be on a higher level, not package-specific, pkgs/.unit-version
- pkg-fun.nix
- pkg
- foo.patch (imported by …/pkg-fun.nix)
- test.nix (imported by …/pkg-fun.nix)
Relative File References
-
@infinisil don’t want to create tooling to automatically fixup relative path
importand other references. -
@infinisil recommends a strict boundary for references with a few rules:
- No
import ../<PATH> - References to “stuff” outside of the package dirs needs to be through function args.
- Anything that currently requires fixup of
../paths by hand, then the automated tooling will ignore them, leaving them to be manually rewritten later.
- No
Tooling
@infinisil: Tooling can be run on a commit history with git filter-branch
We don’t need to worry about old PRs too much
@growpotkin: Dry-run this!
No symlinks and no file changes are great for not triggering merge conflicts in lots of PRs