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
check-meta.nix: implement config.permittedUnfreePackages
#44518
Conversation
You can do this via allowUnfreePredicate right now:
I dunno if it's worth doing here. I guess for consistency with insecure packages it does make sense. I also still have open #43672 to try to standardize these config options a bit. I still haven't figured out how to fix the eval error yet though. |
@matthewbauer Yes, in fact it does exactly that behind the scenes. But, IMHO, exposing a predicate to normal users is meh. "Set |
IMHO Also, |
... similarly to `config.permittedInsecurePackages`.
IMHO `check-meta.nix` is already over-engineered enough, so let's not make it even more complicated.
The actual change of this PR is just
```diff
- allowUnfreePredicate = config.allowUnfreePredicate or (x: false);
+ allowUnfreeDefaultPredicate = x: builtins.elem x.name (config.permittedUnfreePackages or []);
+ allowUnfreePredicate = x: (config.allowUnfreePredicate or allowUnfreeDefaultPredicate) x;
```
which simply duplicates the "Unfree" case up to the renaming of the variables (which, arguably, actually makes things simpler, as in "more consistent"), the rest is to make check-meta errors less copy-pastey and prettier.
I split the patch into two to make this clearer.
Also, `permitted` -> `allowed` for consistency.
The similar option for `Unfree` is named `config.permittedUnfreePackages` and `config.permittedInsecurePackages` for `Insecure`. I'm ok with using either scheme, but renaming those options would be quite a pain, so the current name is consistent enough, I think.
|
72ce706
to
5b4134a
Compare
ping?
|
I have some more ideas about this, will redo later. |
I don't want to have
allowUnfree = true
set and risk accidentally adding something I didn't intend just because I need a single unfree package. On master you can whitelist a single vulnerable package, but you can only whitelist unfree ones together in a single swoop, this fixes it and generalizes docstring generation somewhat.I think broken and unsupported packages should be done the same way, but that's not my itch ATM.