Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib: export namespaced lib as normal overlay #145

Closed
wants to merge 0 commits into from

Conversation

blaggacao
Copy link
Contributor

@blaggacao blaggacao commented Mar 1, 2021

Draft: this still is a public thought journey
Offspring: #147 , blaggacao#3

todo: a flollowup commit could change caller sites within this repo to
use pkgs.devos.lib / nixos.devos.lib, as well.


(Hypothetical) lib-only usage

{
  description = "Flake utils demo";

  inputs.flake-utils.url = "github:numtide/flake-utils";
  inputs.devos.url = "github:divnix/devos";

  outputs = { self, nixpkgs, flake-utils, mach-nix }:
    flake-utils.lib.simpleFlake {
      inherit self nixpkgs;
      name = "my-flake";
      preOverlays = [ devos.overlay ];
    };
}

and then:

{ pkgs, ...}:
   pkgs.devos.lib."[...]"

Namespaceing with litteral devos implies sticky ownership of those parts by divnix/devos.

I reason that this might be the right way of thinking about the ./lib folder, though:

  • If you make changes, chances are good you wanted to upstream them anyway at some point (or maintain a private fork of devos.lib)
  • I'm not sure if I would like to maintain repo-specific library functions in ./lib since that makes syncing with the mothership ever more difficult. I've started by placing repo-specific library functions under ./pkgs

On the other hand, we might also conclude that it is better to namespace with the current project's name, regardless if those are upstreamable changes and encourage to put all repo-specific library functions under ./lib.

Thinking out loud, I'm actually not sure any more. Maybe upgrading ./lib is the better road of the two.

@blaggacao
Copy link
Contributor Author

blaggacao commented Mar 1, 2021

This is sort of the model adopted by https://github.com/numtide/flake-utils/tree/master/examples/simple-flake. Sure for back-compat, we could leave the lib export in flake.nix.

If this is a good idea or not depends on whether lib will become an official first class flake citizen different from packages.

If that is the case, there ought to be contrived a solution to also pass (namespaced?) lib when doing overlays.

@blaggacao
Copy link
Contributor Author

Well, in the latter commit, I did it: dynamic name spacing 😜

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant