-
-
Notifications
You must be signed in to change notification settings - Fork 303
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
plugins/none-ls: refactor using mkSourcePlugin
#1853
Conversation
4dae6fb
to
7f22752
Compare
''; | ||
} | ||
# Only declare a package option if a package is required | ||
// lib.optionalAttrs (packaged ? ${sourceName} || lib.elem sourceName unpackaged) { |
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.
@traxys can you clarify why it is useful to have a separate unpackaged
list?
If we made packaged
into a nullable list, none of the implementation (below) would have to change, but this line could be simplified:
// lib.optionalAttrs (packaged ? ${sourceName} || lib.elem sourceName unpackaged) { | |
// lib.optionalAttrs (packaged ? ${sourceName}) { |
If you just like the list syntax and not needing to spam null
repeatedly, we can use genAttrs
:
packaged =
{
inherit (pkgs)
actionlint
alejandra
# etc
;
}
# Unpackaged
// genAttrs [
"blade_formatter"
"bsfmt"
# etc
] (_: null);
(I agree the package or null or boolean we had before was clunky, so I see the value in the separate noPackage
list).
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.
(I've pushed up a change implementing this, let me know if you'd rather I drop/revert it)
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.
I don't have any issues with that, it was just simpler to write
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.
Some nits/questions, but globally nothing much to say
[ | ||
# As of 2024-03-22, pkgs.d2 is broken | ||
# TODO: re-enable this test when fixed | ||
"d2_fmt" | ||
# TODO: can this be re-enabled? | ||
"yamlfix" | ||
] | ||
++ (lib.optionals (pkgs.stdenv.isDarwin && pkgs.stdenv.isx86_64) [ | ||
# As of 2024-03-27, pkgs.graalvm-ce (a dependency of pkgs.clj-kondo) is broken on x86_64-darwin | ||
# TODO: re-enable this test when fixed | ||
"clj_kondo" | ||
]) | ||
++ (lib.optionals pkgs.stdenv.isDarwin [ | ||
# As of 2024-05-22, python311Packages.k5test (one of ansible-lint's dependenvies) is broken on darwin | ||
# TODO: re-enable this test when fixed | ||
"ansible_lint" | ||
"clazy" | ||
"gdformat" | ||
"gdlint" | ||
"haml_lint" | ||
# As of 2024-06-29, pkgs.rubyfmt is broken on darwin | ||
# TODO: re-enable this test when fixed | ||
"rubyfmt" | ||
"verilator" | ||
"verible_verilog_format" | ||
]) | ||
++ (lib.optionals pkgs.stdenv.isAarch64 [ | ||
"semgrep" | ||
"smlfmt" | ||
# As of 2024-03-11, swift-format is broken on aarch64 | ||
# TODO: re-enable this test when fixed | ||
"swift_format" | ||
]); |
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.
Have you checked that all the packages marked as broken are still broken ?
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.
No I haven't. Is the best way to just empty the list and see what buildbot does?
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.
Yeah I think... We can punt that to another PR
in | ||
lib.mkIf cfg.enable { | ||
# Enable gitsigns if the gitsigns source is enabled | ||
plugins.gitsigns.enable = lib.mkIf gitsignsEnabled true; |
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.
Do you think there is a way to have a warning if gitsigns was not already enabled? I think we will end up with an infinite recursion, but maybe you know a way to to that?
If we can add a warning we could remove this magic in 24.11
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.
I think this is possible by checking the options.plugins.gitsigns.enable.definitions
length.
If the definitions only has one element, then that's our mkIf. If there's multiple definitions then the user has defined it themselves.
Would we also want the warning to check if the final merged value would be true
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 think it's possible, I don't really want to tackle it in this PR.
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.
Yeah no problem
}: | ||
let | ||
inherit (import ./packages.nix pkgs) packaged; | ||
pkg = packaged.${sourceName}; |
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.
Lazy evaluation is nice :D
options.plugins.none-ls.sources.${sourceType}.${sourceName} = | ||
{ | ||
enable = lib.mkEnableOption "the ${sourceName} ${sourceType} source for none-ls"; | ||
withArgs = helpers.mkNullOrOption helpers.nixvimTypes.strLua '' |
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.
It should be straighforward (in another PR) to have structured options here no? We'd need some kind of coercion from string to rawLua though
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.
Agreed. #1705 is tracking the idea.
Introduce `_mk-source-plugin.nix`, which returns a module handling a specific none-ls source plugin. This wasn't possible previously due to IFD conflicting with evaluating module imports. Adjusted the test to use the `options` provided via module args, and cleaned up some stuff allowing "unpackaged" sources to not be listed again in the test file.
56277a0
to
7525906
Compare
We can just make `packaged` nullable again.
7525906
to
06a44e9
Compare
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.
CI fail seems unrelated
@Mergifyio queue |
🛑 The pull request has been removed from the queue
|
@Mergifyio queue |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at 06a44e9 |
This wasn't possible before because we were using IFD, which apparently cannot be used to evaluate module
imports
.Now we can use a "mkModule" style helper, allowing the implementation to be simplified overall. This should also simplify future refactoring, such as an rfc42 "withArgs" equivalent.
I was able to clean the test up a little too, now we don't need to list all "unpackaged" sources in the test; only sources we want to disable from being tested.