Rethink //third_party layout

Opened by tazjin at 2021-04-09T10·00+00

Some current pain points & criticism received:

=> We don't have a consistent nixpkgs.

We could try something else, for example (my suggestion):

Discussions & suggestions welcome!

  1. tazjin changed the subject of this issue from "Rethink //third_party layout" to "Rethink `//third_party` layout" at 2021-04-09T10·00+00
  2. introduce //third_party/overlays (which of course receives the fixpoint), and apply all top-level keys from it as overlays on the imported package set (if we can do this without infinite recursion)

    Note that we will have to have //third_party/overlays/default.nix evaluate to a list which is maintained manually as order of application does matter for overlays.

    Also another suggestion: While we're introducing overlays we should definitely get rid of the stuff exposed as third_party.originals which are only exposed to be overridden which is just essentially a hack to replace overlays (without the benefit of actually joining the nixpkgs fixpoint).

    break the third_party ~= nixpkgs assumption

    One issue I see with this is subtree'd 3p software: If we have a distinction between third_party and third_party.nixpkgs we'll have multiple versions of git, cgit etc. in our closure potentially since people will forget to take something from third_party instead of pkgs.

    The ways out of this I could think of:

    • Adding our custom third_party stuff to overlays, but then the third_party attribute will probably only be useful as a convenience shortcut.
    • Keep the exposed list to prevent people from accidentally using stuff from pkgs we have in third_party.

    sterni at 2021-04-09T19·10+00

  3. Implemented in

    tazjin at 2021-04-10T21·19+00

  4. tazjin closed this issue at 2021-04-10T21·19+00