-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
flake: defragment lib+wrappers, also cleanup tests #2104
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, it feels cleaner and easier to follow the dependency chain of setting up checks. I like not having all the boilerplate for one liners in a few files and searching for the definition.
Looks like something isn't setup right though according to buildbot.
|
||
# TODO: Consider renaming these? | ||
makeNixvimWithModule = import ../wrappers/standalone.nix pkgs flake; | ||
makeNixvim = module: self.makeNixvimWithModule { inherit module; }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what were you thinking for these names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mkNixvim
and mkNixvimWith
- it seems we usually prefer
mk
overmake
, although it's not consistent - the
With
suffix is conventionally used in nixpkgs for a more powerful function variant that takes structured attr args WithModule
is misleading, because both functions take a module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* `WithModule` is misleading, because both functions take a module
This is what was throwing me when looking at their definitions, as well...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I'd like to rename these, I'm hesitant to do so yet as there's other changes I'd like to make and I think we should minimize user-facing refactoring where possible.
In particular, I'd like to get to a point where our lib
(including the standalone wrapper) doesn't depend on pkgs
or system
. This matches the design of other similar flakes like nixos and home-manager, whose equivalent function (e.g. nixpkgs.lib.nixosSystem
) is made available without being in the "perSystem" part of the flake outputs.
Achieving this goal may be fairly involved though and require a few breaking changes and ugly compromises, including re-imagining the standalone wrapper and it's function signature. That'd be the optimal time to rename it, I think.
EDIT: #2186
- Defragment lib-related flake-modules - Expose the standalone-wrapper functions in the `lib`
890686c
to
21c85fd
Compare
21c85fd
to
01ef05e
Compare
lib