mkjson: init at 0.4.0

[athas]

Description of changes

Adds a derivation for mkjson. This program is written in Haskell but is not on Hackage, but I find it quite useful. I could not find any normative documentation for how to handle non-Hackage haskell packages, so I imitated the ones I could find.

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/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (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.

---

Add a 👍 reaction to pull requests you find important.

[maralorn]

LGTM

Not sure if that’s the right directory …

You might consider adding an update-script, but updating by hand is fine if it doesn’t happen that often.

Maybe you also want to expose a separate bin output as a toplevel attribute, because otherwise this app will have a huge runtime closure.

[athas]

It is not updated often enough for a script to be useful.

I can put it in another directory. Which would be the right one?

[maralorn]

I mean that hierarchy is cursed either way …

I guess the haskell/misc folder is more for Haskell specific stuff, so it seems not to fit.

I guess in truth I would prefer all non-hackage-packages to live in the same subfolder. Seeing that all other packages are supposed to move to pkgs/by-name, we ideally hat something like pkgs/haskell/by-name.

But at this point this tool seems similar to jq? So maybe development/tools?

[athas]

Fair enough; I have moved it to development/tools/mkjson. I agree that the by-name scheme is more sensible, but it doesn't exist for Haskell packages at the moment.

[sternenseemann]

doesn't exist for Haskell packages at the moment

Does mkjson have to be in haskellPackages, though? Seems like we could just have a top level binding for it.

[athas]

Perhaps not, but I can't figure out the required plumbing for getting access to all the haskellPackages dependencies it has. I would not mind adding it to all-packages.nix, if that's all it takes.

[maralorn]

doesn't exist for Haskell packages at the moment

Does mkjson have to be in haskellPackages, though? Seems like we could just have a top level binding for it.

Fun point. I kinda thought that’s how we do it. e.g. nix-output-monitor is packaged this way and I guess that doesn’t actually make sense.

@athas It would actually be quite easy to change. Remove the change in non-hackage-packages.nix. And add a

mkjson = haskell.lib.justStaticExecutables (haskellPackages.callPackage ... {});

line to all-packages.nix.

Edit: I kinda hope that there is then a way to translate that to pkgs/by-name, it’s probably also easy, but I have never done that.

[maralorn]

Hah, there is actually precedent for doing this for a Haskell package.

See: https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/ni/nixfmt-rfc-style (you can probably get away with making the package.nix a bit simpler and you don’t need the date.txt and the update.sh)

or https://github.com/NixOS/nixpkgs/tree/master/pkgs/by-name/ln/lngen, which is a bit to simple for my taste, and probably more handwork, but also an option.

I have been convinced that this doesn’t belong in non-hackage-packages.nix

[athas]

Alright, I have done that. I agree that it feels like the right choice. The fact that it is written in Haskell is just an implementation detail; it should not be part of the package name.

[sternenseemann]

It's probably even better to just have a package.nix (in by name) with { haskellPackages }: haskellPackages.callPackage ./generated.nix { } with generated.nix being the output of cabal2nix. package.nix can also add extra overrides of course.

[maralorn]

Yeah, sorry, @athas, as I am also learning this as we go, but I just wanted to remark the same as sterni.

The minimal solution would be a file containing:

{ haskell, haskellPackages }: haskell.lib.justStaticExecutables (haskellPackages.callPackage .. {})

The only reason that the CI is not screaming at you because you are adding a file to the deprecated all-packages.nix is that it does not know what justStaticExecutables is.

[athas]

Alright, I have done that. I like this solution. It also makes it very obvious how to override the package to build manpages etc (for packages that have this, which mkjson doesn't).

[maralorn]

But you dropped the justStaticExecutables now. I would recommend adding that back.

[athas]

Strange, I wonder how that happened.

[maralorn]

Okay, hopefully last thing from me: You should add this to the tested set of the haskell-updates branch now, because otherwise we won’t notice when we break it. (I thought of this when you opened the PR, but while it was in non-hackage-packages the CI would have picked it up automatically.)

The list is here:

nixpkgs/pkgs/top-level/release-haskell.nix

Line 265 in 50e7020

inherit (pkgsPlatforms)

[athas]

I think I did it correctly, but I don't know enough about Hydra to say for sure.

[maralorn]

No, one does. :D

But this looks fine. Let’s see if anyone else has opinions on this for a few hours, but imo this is good to go.

[athas]

I suggest documenting this procedure somewhere (no idea where). It's really not a lot of work once you know what to do, but if you look at the existing infrastructure, it looks very Hackage-centric. I can imagine there's a good number of Haskell applications that are not on Hackage because they are not really intended to be libraries.