What's the purpose of imagemagick_light?

Development
1

The normal imagemagick package is pretty big and contains support for lots of different file formats. The downside of this is, of course, that it pulls in a lot of dependencies, including (parts of) X11. I discovered that there’s an imagemagick_light package and expected that to have a reduced set of dependencies covering only the most common features, but excluding e.g. GUI programs like “display”.

But when I tried to use it, I found that it doesn’t even support JPG and PNG files, and indeed looking at the package definition, it disables support for pretty much every file format. This is puzzling to me: What’s the point of having an imagemagick that can’t handle any images?

2

Up to your use case, I imagine it’s easier/cleaner to override and enable the things you do need than to disable all the stuff you don’t in some cases.

1 Like
3

Ah, so it’s a “baseline” to which you can add individual features? Btw, it seems the ImageMagick variants aren’t documented, there’s also imagemagickBig, which includes GhostScript support. What would be the right place to add this documentation?

4

They are, or at least the packages are marked as searchable: NixOS Search

Where were you expecting this documentation?

Kinda, it’s possible to do that with all nix packages, the intent behind this one seems more like a convenience thing.

Maybe illustration helps. Caveat small errors on my side, these NixOS modules are equivalent:

{ pkgs, ... }: {
  environment.systemPackages = with pkgs; [
    (imagemagick_light.override {
      ghostscriptSupport = true;
    })
  ];
}

{ pkgs, ... }: {
  environment.systemPackages = with pkgs; [
    (imagemagick.override {
      ghostscriptSupport = true;
      bzip2Support = false;
      zlibSupport = false;
      libX11Support = false;
      libXtSupport = false;
      fontconfigSupport = false;
      freetypeSupport = false;
      libjpegSupport = false;
      djvulibreSupport = false;
      lcms2Support = false;
      openexrSupport = false;
      libjxlSupport = false;
      libpngSupport = false;
      liblqr1Support = false;
      librsvgSupport = false;
      libtiffSupport = false;
      libxml2Support = false;
      openjpegSupport = false;
      libwebpSupport = false;
      libheifSupport = false;
    })
  ];
}

Obviously, the former is cleaner if you only need ghostscript support.

That said, there isn’t exactly a policy for this kind of thing to my knowledge, so this is probably an ad-hoc decision by whoever maintains these packages. Likely multiple people, given the inconsistency between snake_case and camelCase.

2 Likes
5

Yes, they are there, that’s how I found them. But their descriptions are all identical. Also, their “Source” links all point to the package module, not to all-packages.nix where they are actually defined, so there’s no way to find out more about them without diving into the nixpkgs repository.

I’d like to document that information somewhere, but it’s not clear where it should go.

6

This is true for all “variant” packages. The description and source location for all of them come from nix evaluating the derivation, and since that’s ultimately the same for all three their metadata is identical.

The current place such docs could fit is the nixpkgs manual, but it’d explode if we added docs for every package that does this.

The underlying problem is a limitation of search.nixos.org though, and the problem behind that is probably lack of enthusiastic independent manpower.

There have been various calls for more rich metadata (e.g. a generic “usage” field would be nice, as would links to NixOS options, to prevent people from using packages intended to be used by modules directly and getting confused, and “variants” could really help deduplicate kernels and other multi-version stuff).

There’s an open issue about your specific problem, too: Explain differences between certain packages · Issue #725 · NixOS/nixos-search · GitHub

I think generally the nix search stuff isn’t deemed important enough for RFCs, but tbh IMO that site is one of the most important services in the ecosystem and should be improved significantly (and better CLI search would be cool too, as people often point out, so getting a clearer standard for how search should work in the process would be awesome, etc.).

Would be interesting to find a group to rally around to improve matters a bit, but yeah, the ecosystem has a bit of a governance problem, nobody knows who to ask and those that do are too busy ;p