-
-
Notifications
You must be signed in to change notification settings - Fork 266
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
Better package
option helpers
#2004
Comments
I wonder if the option default would be lazy if we didn't evaluate the default package's |
As I understand it, Therefore, the main blocker to making package-type option defaults "lazy" is either not including the docs in the final build or not having The only thing I'm confused about, is when including the man-docs, we include the package from our flake outputs. It's probably better practice to build the docs using the |
I wonder if its enough to not avoid evaluating the package defaults, but instead allow them to fail gracefully. We could probably just wrap the We'd still want to check that plugins have a valid url on our nixpkgs lock, but this could be done in a new test instead of during module eval. |
I'd like to achieve two things here:
mkPackageOption
helper withdefaultText
#1950The first point should be achieved by providing the helper with a "pkgs path" that can be used with
getAttrByPath
and alsoconcatStringsSep "."
to providedefault
anddefaultText
respectively.I'm not sure about the second point. Maybe we'd need a different type that is lazier, although this may break things like
mkIf
.Or maybe we can do something like
either package (functionTo package)
and provide a lazy function that returns the package as the default?The text was updated successfully, but these errors were encountered: