2022-01-09 Nixpkgs Architecture Team Meeting #24

Development Nixpkgs Architecture
1

Nixpkgs Architecture Team Meeting #24

Notes

Should PRs follow new convention?

  • For some period accept both old and new convention.

  • Should reviewers require the new convention?

  • @Ericson2314: This sounds like an edge case, possibly overcomitting.

  • @growpotkin and @Ericson2314:

    • New PRs of new code should follow the new convention.
    • Old PRs predating the convention (that should have gotten review earlier) should not be penalized.

  • Infinisil: Well the automated tool can handle the new code so maybe it’s not so bad?

    • @growpotkin & @Ericson2314: Well then the tool is committing itself to handle arbitrary simple PRs going forward rather than just the old stuff that already exists.
    • @infinisil:
    • @Ericson2314: The PR auther can also use the tools to migrate their own PR / be responsible for fixing anything that doens’t match it.
    • @infinisil: Do we need any changes then?

  • Newly added packages ought to follow new conventions, existing packages can be
    updated without migration.

    • Use common sense, etc.

  • Non-gating PR checks to report whether a package can be auto-migrated.

    • Gray check indicates failure, but won’t block a PR.

  • Make it less restrictive by removing check #2, let people migrate all the packages they want

builtins.unsafeGetAttrPos breakage with unit/

  • Moving packages causes breakage to builtins.unsafeGetAttrPos.
  • @growpotkin: Not a serious issue. It’s “unsafe” - you were told.
  • @roberth: Seems like they misunderstood the routine. Non-issue.
  • @Ericson2314: Non-issue.
  • Finding packages should be a non-issue because they can be located
    in their unit/ directory “by name”.

Action items