Skip to content
This repository has been archived by the owner on Mar 11, 2024. It is now read-only.

Latest commit

 

History

History
109 lines (91 loc) · 4.48 KB

2022-11-28.md

File metadata and controls

109 lines (91 loc) · 4.48 KB

Nixpkgs Architecture Team Meeting #19

Notes

Issues

Simple Package Paths

  • @infinisil created PR associated with sharding directory names.
  • 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.path

    nixpkgs
pkgs = import nixpkgs {}
pkgs.path == nixpkgs

    Probably 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

pkgs/unit/hell/hello/unstructured/test.nix

nixpkgs-architecture/simple-package-paths#19

  • Protected namespace for misc files associated with a package.
  • Makes existing files with common names distinct from new "standardized" filenames.
    • Example: test.nix might exist in a package today, but may not follow standardized structure for "new" pkgs/unit/<SHARD>/<PNAME>/test.nix checks.
      • NOTE: I have no idea if test.nix is a prospective "standardized" file, I'm just providing an example.
    • @roberth: Since for now we only have packages, let's use a pkg subdirectory for all extra package-related files
      • @infinisil: +1
      • @growpotkin: Spell out package to avoid annoying completion?
        • @infinisil: pkg/fun.nix instead of pkg-fun.nix?
          • @roberth: Right direction. Goes into removing initial pkgs nesting, but we agreed to not do that
        • pfunk.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

Proposals:

  • pkgs/unit/gnum/gnumake

    • pkg-fun
      • pkg-fun.nix
      • foo.patch (imported by pkg-fun.nix)
      • test.nix (imported by pkg-fun.nix)

  • 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 import and 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.

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