Well, I did it like this (an overlay, for the other Nix related packages too)

packages = {...} // lib.listToAttrs (
        lib.mapAttrsToList
          (name: val: {
            name =
              let
                replacedNames = {
                  lix = "nix";
                };
              in
              if pkgs.lib.hasAttr name replacedNames then pkgs.lib.getAttr name replacedNames else name;
            value = val;
          })
          (
            lib.filterAttrs (
              _: v: lib.isDerivation v
            ) inputs.nixpkgs.legacyPackages.${system}.lixPackageSets.git
          )
      );

Half baked idea for a new pair of builtins: builtins.restrictNamespace and builtins.restrictedNamespace (feel free to suggest a different color for the bikeshed). Here's the basic idea:

Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + 1);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in 6. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in an eval error about foo being inaccessible in a restricted namespace. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

hits the builtins.throw case.

Not sure how this would/should interact with builtins.scopedImport.

Motivation for wanting this is that it allows you to restrict the names available to some expression without forcing that expression to be moved into a different file. Good idea, bad idea, thoughts?

Half baked idea for a new pair of builtins: builtins.restrictNamespace and builtins.restrictedNamespace (feel free to suggest a different color for the bikeshed). Here's the basic idea:

Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + 1);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in 6. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in an eval error about foo being inaccessible in a restricted namespace. Evaluating this:

let
  foo = 4;
  bar = x: x + foo;
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

hits the builtins.throw case.

Not sure how this would/should interact with builtins.scopedImport.

Motivation for wanting this is that it allows you to restrict the names available to some expression without forcing that expression to be moved into a different file. Good idea, bad idea, thoughts?

Half baked idea for a new pair of builtins: builtins.restrictNamespace and builtins.restrictedNamespace (feel free to suggest a different color for the bikeshed). Here's the basic idea:

Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + 1);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in 6. Evaluating this:

let
  foo = 4;
  bar = builtins.restrictNamespace (x: x + foo);
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

results in an eval error about foo being inaccessible in a restricted namespace. Evaluating this:

let
  foo = 4;
  bar = x: x + foo;
in

if !(builtins.restrictedNamespace bar)
  then builtins.throw "bar's namespace is required to be restricted"
  else bar 5

hits the builtins.throw case.

Not sure how this would/should interact with builtins.scopedImport.

Motivation for wanting this is that it allows you to restrict the names available to some expression (in this case a function, but ideally this'd work for any expression) without forcing that expression to be moved into a different file. Good idea, bad idea, thoughts?