nixfmt-classic: add (eventual) deprecation and removal

[jfly]

This implements steps 1 and 2 of our nixfmt-classic deprecation plan: NixOS/nixfmt#340.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[jfly]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 447790
Commit: 93627b2595ca3f6a8b003d0344ef5c277251d98e

[MattSturgeon]

I wonder if we should be doing the deprecation (i.e. step 2) at the underlying haskellPackages.nixfmt package? Since the top-level nixfmt-classic is already just an alias for it...

I can't see if/how/where the haskellPackages set handles aliases and deprecation, though... Nothing obvious in the entrypoint. Maybe @NixOS/haskell will know?

Whatever we do should be gated behind config.allowAliases, of course.

[sternenseemann]

Needs to be implemented manually, you can grep for allowAliases. Note that package removal is currently not possible (in a sensible way), but will probably be implemented sometime this autumn (cc @wolfgangwalther).

[MattSturgeon]

I spoke to @wolfgangwalther async:

haskell packages are auto-generated. You can't add aliases. You can only do this at the source once #441204 is done, by removing the package from haskellPackages. For now you need to alias it on the top-level only.

So I believe the correct thing to do is merge this as-is, then move the deprecation into the haskellPackages scope if/when that package-set adds support for deprecating specific packages.

Naïvely, we could add an overlay to the end of haskellPackages's extensions stack, and have that overlay implement the deprecations:

(final: prev: lib.optionalAttrs final.config.allowAliases {
  nixfmt =
    (
      if lib.oldestSupportedReleaseIsAtLeast 2605 then
        throw "haskellPackages.nixfmt has been removed as it is deprecated and unmaintained."
      else if lib.oldestSupportedReleaseIsAtLeast 2511 then
        lib.warnOnInstantiate "haskellPackages.nixfmt is deprecated and unmaintained. We recommend switching to nixfmt."
      else
        lib.id
    )
      prev.nixfmt;
})

However, this means that the package will still be present without any deprecation when allowAliases = false, which is unusual. That's because the package is automatically generated from hackage, so we can't move its base definition to a conditional extension.

[MattSturgeon]

Moving the deprecation to the underlying haskellPackages scope seems non-trivial, so I believe merging this as-is is correct for now.

Thanks @jfly

[jfly]

Thanks, @MattSturgeon! Could you merge this?

[MattSturgeon]

Could you merge this?

Yep. I didn't want to merge immediately in case anyone else had additional feedback.