I don't necessarily want to argue against this change, but in the past we have generally only provided Haskell packages at the versions locked in the LTS release we are tracking. We generally don't provide top-level packages for Haskell package versions that are newer than in LTS.

We have an open issue about this: #190542

Is there some reason you think that ShellCheck should be "special" in this regard, and have the top-level package be the latest version (as opposed to whatever version is in the LTS)? It generally creates more work for the Haskell team to have packages tracking a version not in the LTS (not that this is a super-important reason).

It used to be that shellcheck was always the newest version but that override was dropped for some reason. (IIRC it was somewhere in the haskell tooling outside this repo)

Is there some reason you think that ShellCheck should be "special" in this regard, and have the top-level package be the latest version (as opposed to whatever version is in the LTS)?

TBH I think this is looking at it wrong. LTS tracking is only relevant because this happens to be written in haskell which is a detail users most likely don't care about. Is there a reason to not have the newest version of this tool?

I did the same PR a year ago: #147780

It generally creates more work for the Haskell team to have packages tracking a version not in the LTS ...

Is there any way to have pkgs.shellcheck be independent of haskellPackages, e.g switch to using a FOD for the deps?

Is there any way to have pkgs.shellcheck be independent of haskellPackages, e.g switch to using a FOD for the deps?

We unfortunately don't have any way of doing this for the Haskell stuff in Nixpkgs right now. (Although I agree this would potentially be a better solution for a package like shellcheck. The top-level purescript package is somewhat similar, and if you take a look at the derivation you'll see that we're distributing patchelf'd binaries, instead of building from source.)

Is there a reason to not have the newest version of this tool?

It causes slightly more work for the Haskell maintainers here in Nixpkgs. When a new version of ShellCheck is released (like 0.9.1), haskellPackages.ShellCheck_0_9_0 will no longer be available (instead we'll only have haskellPackages.ShellCheck_0_9_1), and one of us will have to manually update the reference here in all-packages.nix. It creates extra work for us.

Not that I think that is necessarily a reason to prevent this PR from being merged in.

... distributing patchelf'd binaries ...

shellcheck upstream doesn't have binaries for many platforms so this probably isn't an option at the moment.

Is there a reason to not have the newest version of this tool?

It causes slightly more work for the Haskell maintainers here ...

Yes, sorry I meant besides that. I am sympathetic to not wanting more work and that every little bit adds up but not providing the newest version of a dev tool seems a bit odd.

Also shellcheck doesn't release very often so likely the next time this needs to be touched will to remove it as 0.9.0 is the default.

shellcheck upstream doesn't have binaries for many platforms so this probably isn't an option at the moment.

Ah, I was agreeing with you that not having some sort of FOD builder for Haskell is unfortunate, and the purescript situation is less-than-ideal!

Also shellcheck doesn't release very often so likely the next time this needs to be touched will to remove it as 0.9.0 is the default.

That makes sense, and sounds like a good reason to go ahead with this change.

It used to be that shellcheck was always the newest version but that override was dropped for some reason. (IIRC it was somewhere in the haskell tooling outside this repo)

Those overrides actually exist within nixpkgs and I cleaned them up a while ago. Not sure if shellcheck was in there at that point. Maybe we can introduce a policy that any maintainer of a package is allowed to enter their package there (with a comment).

Those overrides actually exist within nixpkgs

Oh, thanks. I had looked through haskell-modules history but I forgot about the scripts in maintainers.

Not sure if shellcheck was in there at that point.

Looks like it was: bf3a3b6

Maybe we can introduce a policy that any maintainer of a package is allowed to enter their package there ...

I'm not maintaining it currently but if this approach makes things easier I can add myself. My haskell knowledge is rather limited so I probably won't be of much use if the package breaks in a non-trivial way.

You have proven enough nix knowledge to be fully qualified for a maintainership. Deep Haskell knowledge is rarely required and if it is, you can always ask in #haskell:nixos.org.