lib,lsp,none-ls: Add a standard way to handle automatic installation of packages that may not exist in nixpkgs #2852
Conversation
…ages For example for lsp it can generate the following kind of messages: error: Nixvim (plugins.lsp.servers.ziggy_schema.package): No package is known for ziggy_schema, install externally and set this option to null
| }; | ||
|
|
||
| useOptionalPackage = | ||
| options: config: opt: |
There was a problem hiding this comment.
| options: config: opt: | |
| options: config: loc: |
or
| options: config: opt: | |
| options: config: path: |
(not sure we really need config either, because we have opt.value available)
| useOptionalPackage = | ||
| options: config: opt: | ||
| let | ||
| def = lib.getAttrFromPath opt options; |
There was a problem hiding this comment.
| def = lib.getAttrFromPath opt options; | |
| opt = lib.getAttrFromPath loc options; |
| in | ||
| if !def.isDefined && def ? _unpackaged then | ||
| throw '' | ||
| Nixvim (${lib.concatStringsSep "." opt}): No package is known for ${def._packageName}, install externally and set this option to null |
There was a problem hiding this comment.
| Nixvim (${lib.concatStringsSep "." opt}): No package is known for ${def._packageName}, install externally and set this option to null | |
| Nixvim (${opt}): No package is known for ${opt._packageName}, install externally and set this option to null |
options have a __toString which uses showOption opt.loc, which is a bit nicer than using the loc we have passed in, because it also gets things like the prefix (programs.nixvim).
Not sure where opt._packageName comes from?
| Nixvim (${lib.concatStringsSep "." opt}): No package is known for ${def._packageName}, install externally and set this option to null | ||
| '' | ||
| else | ||
| lib.getAttrFromPath opt config; |
There was a problem hiding this comment.
| lib.getAttrFromPath opt config; | |
| opt.value; |
| // { | ||
| _unpackaged = true; | ||
| _packageName = name; | ||
| }; |
There was a problem hiding this comment.
Does this survive the module system? I'm pretty sure particular parts of the module system that elaborate options will only inherit known attrs.
There was a problem hiding this comment.
From what I tested it does (as I managed to trigger the warnkngs
| @@ -391,6 +391,39 @@ rec { | |||
| ); | |||
| }; | |||
|
|
|||
| mkOptionalPackage = | |||
There was a problem hiding this comment.
initial impression: this feels like an anti-pattern. Can we find a way to "use" an optional package without having to declare the option in a special way?
If such a package is used by an end user an error will be raised with a message of the form:
I'm open to changing that to a warning and returning null instead, though this would complicate the implementation as we would now need to check the priorities