@GrahamcOfBorg build jackline

About ocamlPackages.callPackages: besides cosmetic differences (e.g., number of arguments to the package), the main impact seems on overriding. In one case it is easy to override a single OCaml library, in the other case, it is easy to override the whole set of OCaml dependencies.

What case is more likely? Trying out with a custom version of, say, mirage-crypto or trying out with a different version of OCaml?

For the moment 4.08 is the only version jackline will work in nixpkgs (until we package the community maintained camlp4 for 4.09, 4.10, 4.11, …). On the other hand jackline, having no stable releases, generally should be built with the latest library versions (almost all of them are pinned to their latest versions currently).

So I suppose as soon as we have camlp4 for ocaml >= 4.09, ocaml is more likely to be overridden. What do you think?

Regarding camlp4, it might be more valuable to rewrite the parser for SASL without the stream-parser notation of camlp4…

Regarding jackline in nixpkgs, I prefer without the last change. Indeed, it would allow to write: jackline.override { inherit (ocamlPackages) tls; }. Such a nonsense is much harder to write when the package expects a single argument for a consistent set of OCaml libraries.

But you are the maintainer.

Alright, I'm keeping it as it was.

Regarding camlp4: How do you feel about the community maintained version of camlp4 (https://github.com/camlp4/camlp4)? I haven't looked into it at all so far, so I can't say if it's worth packaging it at all or if it's just better to write a PR for erm_xmpp dropping the camlp4 dependency (which is planned anyways).

IMHO, it is better not to package camlp4 for recent versions of OCaml: legacy programs that depend on it can use legacy versions of OCaml (4.08 is not yet very old); maintained program should find a way out of camlp4…

In the particular case of erm_xmpp, it shouldn’t be a lot of work to rewrite the parser using menhir or some combinator library (e.g. angstrom).