nushellPlugins.*: refactor, add checks, mark some as broken

[dtomvan]

This PR modernizes the 12 existing nushell plugins in the repo. I noticed a lot of copy-pasting has been done, with a lot of the same problems in it, so I did all of it in one go.

The new packages should be functionally equivalent, because all I did was reformat/rearrange things.

Summary:

• Did some trivial stuff like use finalAttrs and remove with lib;
• Removed useCargoFetchVendor
• Some packages had weird testing/workspace practices. Replaced those with buildAndtestSubdir, checkFlags etc. instead of a manual checkPhase
• Renamed nushell_plugin_* -> nu_plugin_* to reflect the main binary name (for versionCheckHook and consistency because there were already files with nu_plugin_* as pname)
• Removed meta.platforms.all
• Removed references to pname
• Added versionCheckHook to all of them
• Added a check that tries to load the plugin to all of them

I did all of it manually, which is error-prone but I didn't think it was worth automating.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[dtomvan]

I hope that, when I undraft this, I don't ping like ~20 people. I am afraid that's what has to happen if you refactor 12 packages as once. I am sorry in advance if this causes anybody any trouble.

[dtomvan]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 420675
Commit: f3a980217d854abd10161f9c6525724e43d6da44

---

x86_64-linux

✅ 11 packages built:

• nushellPlugins.dbus
• nushellPlugins.formats
• nushellPlugins.gstat
• nushellPlugins.hcl
• nushellPlugins.highlight
• nushellPlugins.net
• nushellPlugins.polars
• nushellPlugins.query
• nushellPlugins.semver
• nushellPlugins.skim
• nushellPlugins.units

[aftix]

Is this needed? Upstream might add tests in the future which will then be ignored until someone stumbles upon on this line.

[happysalada]

You can test, but i seem to remember that yes it is needed.

[dtomvan]

Just following https://github.com/NixOS/nixpkgs/blob/d85e3b87ffdc6e879499e54599a9d606b90955ce/doc/languages-frameworks/rust.section.md#disabling-package-tests-disabling-package-tests here:

If no tests exist -- the checkPhase should be explicitly disabled to skip unnecessary build steps to speed up the build

[aftix]

I never added the smoke test to every plugin since I couldn't decide where to put it, but I think making a local install check hook would be good.

[mgttlinger]

Looks good to me

[happysalada]

I dont think the changes here are very controversial, im thinking of merging this in 24h. Happy to delay, if anyone needs time, just post a message.

[happysalada]

Oh minor thing actually, there are 59 commits, could you squash then into one commit per package ? I dont think we need that granularity for those changes.

[dtomvan]

I thought of doing that. But I was hoping this granularity would allow for an easier review process (before and after this merge)

Also, each remove lib.platforms.all commit has an explanation next to it, or is it all clear on its own why I did what I did?

[dtomvan]

I've kept the old version of the branch around, so I can revert it back if anyone objects to the suggestion by @happysalada

[dtomvan]

Turns out some of them are broken because they are outdated. Marking them as such. Only found that out because I added the smoke test to all of them. Turns out that's already paying off 😅

[dtomvan]

Also, should this get backported to stable (except for marking units and net as broken, since they support the nushell version in 25.05, 0.104.0) so that any plugin updates that might happen could be backported automatically to stable?

[timon-schelling]

While rebasing #420202 and #420876 I noticed that the check version test fails for plugins with version {version}-unstable-{date} and other similar cases.

Sure, patching the version in Cargo.toml is an option.

substituteInPlace Cargo.toml \
      --replace-fail 'version = "${lib.head (lib.splitString "-" finalAttrs.version)}"' 'version = "${finalAttrs.version}"'

But I don't like patching only to pass that check.

It feels like this pr introduced a "policy" to nushellPlugins that disallows plugins where the version that is defined in the code and the way we name that version in nixpkgs are different.

This will lead to problems when trying to update plugins after a nushell-protocol update.
Some plugins bump nushell-protocol without incrementing the version.
See https://github.com/yybit/nu_plugin_compress/commits/main/
And I think we should not interfere with that decision.
This is a case where {version}-unstable-{date} should be used, in my opinion.

I suggest using a version test that allows this.

[dtomvan]

You can set dontVersionCheck? I figured it was a good idea to have these things blow up in your face if something might be wrong, but if it doesn't work with your usecase, AFAIK you can turn off the checks I introduced manually. If you set dontVersionCheck you might want to introduce a test with testers.testVersion though. Or is your suggestion to move all of them to testers.testVersion (and split the package version on -unstable- and only use the first part for the check)?

[timon-schelling]

Maybe like this #421842 yes.

dontVersionCheck etc. would make updating more complex and add extra things to think about for every plugin.

[dtomvan]

I don't see why, because in theory these plugins can get updated seamlessly by r-ryantm and maintainers wouldn't need to do a lot about it except test and merge the bot PR. Currently I don't see any plugin that has unstableGitUpdater or nix-update-script with --version=branch, so as far as existing plugins are concerned this is a non-issue.

[timon-schelling]

I don't see why, because in theory these plugins can get updated seamlessly by r-ryantm and maintainers wouldn't need to do a lot about it except test and merge the bot PR. Currently I don't see any plugin that has unstableGitUpdater or nix-update-script with --version=branch, so as far as existing plugins are concerned this is a non-issue.

I thought about plugins where we have something like the following on a regular basis.

nushell 0.105.0 -> 0.106.0 | compatible plugin version 0.1.2 -> 0.1.2-unstable-2022-05-09
nushell 0.106.0 -> 0.107.0 | compatible plugin version 0.1.2-unstable-2022-05-09 -> 0.1.2-unstable-2022-05-31
nushell 0.107.0 -> 0.108.0 | compatible plugin version 0.1.2-unstable-2022-05-31 -> 0.1.3
nushell 0.108.0 -> 0.109.0 | compatible plugin version 0.1.3 -> 0.1.4
nushell 0.109.0 -> 0.110.0 | compatible plugin version 0.1.5 -> 0.1.5
nushell 0.110.0 -> 0.111.0 | compatible plugin version 0.1.5 -> 0.1.5-unstable-2022-07-31
nushell 0.111.0 -> 0.112.0 | compatible plugin version 0.1.5-unstable-2022-07-31 -> 0.2.0
nushell 0.112.0 -> 0.113.0 | compatible plugin version 0.2.0 -> 0.2.0-unstable-2022-08-15