Multiple packages, single release

Ecosystem
,
1

Hi,

I’m one of the co-maintainers of the ZMQ library. This library has one main part, zmq and two optional libraries, zmq-async and zmq-lwt. When we run our CI we want to try installing either of the optional packages. This also means, that the main library needs to be installed. The problem is now with versioning.

When we build on Travis we’d like to install them in the exact versions that are present the commit that is being built. We have a .travis.yml where we pin all versions, but unfortunately the build fails because zmq-lwt depends on zmq that is >= 5.1.0 and that is not in OPAM (how could it, given this is the release commit). It doesn’t pick up the version from the repo at all. How do I get this fixed?

Similarly, when releasing, how can I make sure that all the packages depend on each other in the right version? I release with dune-release which is nice since I only need to write the version into CHANGES.md once, but I would like to get the opam files of zmq-async and zmq-lwt have a constraint on zmq {= "5.1.0"} or whatever the version I am releasing is.

I can’t be the only one who runs in these issues with sublibraries, how do people solve that properly?

1 Like
2

For that particular problem you can use the opamv2 {= version} constraint. E.g. topkg and topkg-care must have matching versions so in topkg-care, which depends on topkg I have:

depends: [
"topkg" {= version }
]
2 Likes
3

We have our own opam repository called “testing” in which each package (and we have about a few dozens of them) is pointing not to archive, but to a git repository. Not only it enables so called rolling release (so that each commit to the master branch is immediately available in OPAM), but it also facilitates CI as your example highlights.

Here is how this repo looks like. To enable custom repo just add via opam repo add <name> <url>.

4

This is a good solution but it takes away some of the user’s freedom to choose different versions of individual packages. It’s usually not a big deal, but in zmq’s case I can make an argument that why this is a useful thing to have and that it mixing and matching versions this way.

5

The alternative is to put a specific or a high version in the pins: PINS=“zmq.100.0:.” will pin zmq with version 100.0