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

Better package option helpers #2004

Open
1 of 2 tasks
MattSturgeon opened this issue Aug 10, 2024 · 3 comments
Open
1 of 2 tasks

Better package option helpers #2004

MattSturgeon opened this issue Aug 10, 2024 · 3 comments
Labels
tech debt Related to technical debt and/or refactoring

Comments

@MattSturgeon
Copy link
Member

MattSturgeon commented Aug 10, 2024

I'd like to achieve two things here:

The first point should be achieved by providing the helper with a "pkgs path" that can be used with getAttrByPath and also concatStringsSep "." to provide default and defaultText 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?

@MattSturgeon
Copy link
Member Author

I wonder if the option default would be lazy if we didn't evaluate the default package's meta.homepage? Although, maybe that's only evaluated when rendering the docs?

@MattSturgeon
Copy link
Member Author

As I understand it, meta.nixvimInfo.url usually depends on evaluating the package, however this will only be evaluated when building the docs.

Therefore, the main blocker to making package-type option defaults "lazy" is either not including the docs in the final build or not having meta.nixvimInfo.url default to the <pkg>.meta.homepage and instead always set url to a string literal...

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 pkgs available in the module eval (see #2186), however using the flake output should mean that mismatched pkgs channel errors are not possible, unless the flake inputs are overridden using follows...

@MattSturgeon MattSturgeon added the tech debt Related to technical debt and/or refactoring label Sep 7, 2024
@MattSturgeon
Copy link
Member Author

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 package.default.meta.homepage in tryEval.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tech debt Related to technical debt and/or refactoring
Projects
None yet
Development

No branches or pull requests

1 participant