nixos-option: cleanup and linting#355748
Conversation
b46c1d7 to
895c4ea
Compare
Before the code was using include-what-you-means, but it's a bit tricky to integrate this in nix. I had some trouble with nix-eval-jobs when using include-what-you-means. clang-tidy on the other hand proved more robust to me and is useful for linting in general, so less tooling overall for this little project.
to make the linter happy.
e2af8ab to
8086ffc
Compare
|
cc @xokdvium |
xokdvium
left a comment
There was a problem hiding this comment.
In general LGTM module the above comments and the noisy diff because of modernize-use-trailing-return-type. It's purely stylistic, but it's fine by me if that's intended.
8086ffc to
cf11719
Compare
Looks like the other pull request is still not finished as well. What's you ETA on that? |
Right, but Unrelatedly, nixos-option has been causing wasted closure size and annoyance to Lix users since the inception of Lix (and wasted closure size for CppNix users for even longer because nixos-option is unmaintained and usually pinned to some old CppNix version it builds with), while being fragile code by virtue of linking to the CppNix API and being maintained in nixpkgs where the tooling support for hosting a C++ project is not great and where there are very few maintainers for in-tree C++, which is why it is in the poor state you found it in. I am saying this as the person who has done multiple fixes to nixos-option because they needed doing, including the one that was urgently done so that Nix 2.16 (or something like that) could be properly dropped in January when the fod corruption security bug happened. The C++
I don't know. I know that it was at one point in a perfectly mergeable state right before flakes support was being added, introducing a bunch of lack of clarity as to what was the right approach. It could probably have the flake support removed in an hour of concerted effort and be simply merged. |
|
I believe nothing in this pull request complicates the completion of the other pull request. Therefore, I don't see a strong justification for delaying these maintenance fixes to the current implementation while waiting for a rewrite that hasn't yet been widely tested. If it's really just a matter of an hour, I would suggest just finishing it, especially since the actual reason for you being against it is the dependency of nix rather the content of this pull request. With that in mind, I propose moving forward with merging this pull request within the next two weeks unless there are strong objections from NixOS maintainer or the other pull requests gets merged first. cc @NixOS/nix-team |
tomberek
left a comment
There was a problem hiding this comment.
Looks like it is mostly style and standardizing the code. No objections. Thanks!
As noted, several weeks have passed. Merging.
|
This links the tests for nixos-option so it's more obvious what to tests: #363967 |
Things done
Depends on #355745
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.