I’m after some help and advice on packaging a large OCaml project up for OPAM.
I’m working on a native OCaml project for AWSinhabitedtype/ocaml-aws. The project uses the service defintions published via
botocore and uses a generator to give OCaml. As it currently stands the project is split into the following
- aws - core http / serialisation / error handling code
- aws-lwt - thin wrapper to use lwt
- aws-async - another thin wrapper to use async
- aws-* - a library per service eg RDS, EC2
Each part has it’s own *.opam file, so I would expect to push each to opam as a library.
Does this split make logical sense for an OCaml library? I’m following the experience I had with
a similar Haskell library (amazonka) which worked nicely.
How can I package up each library for OPAM, with as automated process as possible?
The last time I tried this none of the available tools like opam-publish/dune release worked well with multiple libraries in a single github repo.
Right now I have working interactions with a reasonable selection of services:
autoscaling, cloudformation, cloudtrail, cloudwatch
ec2, elasticache, elasticloadbalancing, rds
route53, sdb, sqs, ssm, sts
The challenge I have is testing each service properly to ensure I don’t break something when adding new services or hacking on the code generation. Right now I have a bunch of unit-tests that hit individual services and do some basic things. This approach isn’t going to scale particularly well, the tests are somewhat slow once you wait for real resources to spin up, and the monetary cost of AWS resources will get too much for an individual to cover. I am thinking I will write a selection of basic scenario tests to use free-tier resources and also provide a cli client that replicates the official cli client so that other tests can be done ad-hoc.
Thoughts? Is there other options I haven’t considered.
- How can I package up each library for OPAM?
- How can I best test the library without incurring significant overhead or cost?