Re: Packaging OCaml repositories that define multiple packages?

[Csepp <raingloom@riseup.net>]

Csepp <raingloom@riseup.net> writes:

> Thanks!  Yeah, the alias solution was not pretty.  Guess I'll use
> inherits and set the package argument.
>
> Julien Lepiller <julien@lepiller.eu> writes:
>
>> The importer will not support such a package. As you say, it wants to
>> build them separately because they are separate opam packages. So,
>> either we build them separately too, or we build all at once.
>>
>> If we build all at once, that's fine. You could name the package
>> ocaml-mirage and not use any #:package argument. Dune will then build
>> all packages from the repository.
>>
>> One issue with that is that the importer will not know about it and will try
>> to import subpackages again whenever a packages depends on it, instead
>> of using ocaml-mirage.
>>
>> I don't like the alias solution, though it should work, since the importer
>> would see them.
>>
>> Le 8 janvier 2023 15:04:35 GMT+01:00, Csepp <raingloom@riseup.net>
>> a écrit :
>>
>>  I'm going through my MirageOS commits for what is hopefully
>>  the last
>> time before I send the patches and I realized that a problem that I
>> thought was isolated is a lot more widespread than I thought.
>>
>> As an example look at https://github.com/mirage/mirage/
>>
>> It defines functoria, functoria-runtime, mirage, and mirage-runtime.
>>
>> It is possible to build all 4 as one package.
>>
>> The opam importer seems to not be able to handle situations like this,
>> since it defines a new package for each sub-package.
>>
>> How should I proceed?  I definitely want to merge all redundant packages
>> into one, but then what?  How should the package description reflect
>> this?  What should the package be named when it corresponds to 4 OPAM
>> packages at once?
>>
>> For now I defined a few aliases for cases like this, but I'm not sure if
>> this is ideal.  They look like this (made up but possible example):
>> (define ocaml-mirage ocaml-mirage-runtime)

Switching to bottom replying, I hope you don't mind.

So, I converted most definitions to variants, as discussed.  That
covered all the packages that I introduced that had subpackages, like
the {mirage,functoria}[-runtime] foursome.
But there are packages that were added by others that already specify
which subpackage they build, and yet seem to be accepted as subpackages.
I worked around these using the somewhat aesthetically unpleasant
aliasing solution.