* Packaging OCaml repositories that define multiple packages?
@ 2023-01-08 14:04 Csepp
2023-01-08 15:17 ` Julien Lepiller
0 siblings, 1 reply; 6+ messages in thread
From: Csepp @ 2023-01-08 14:04 UTC (permalink / raw)
To: Guix Devel; +Cc: Julien Lepiller, pukkamustard
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packaging OCaml repositories that define multiple packages?
2023-01-08 14:04 Packaging OCaml repositories that define multiple packages? Csepp
@ 2023-01-08 15:17 ` Julien Lepiller
2023-01-08 19:52 ` Csepp
0 siblings, 1 reply; 6+ messages in thread
From: Julien Lepiller @ 2023-01-08 15:17 UTC (permalink / raw)
To: Csepp, Guix Devel; +Cc: pukkamustard
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
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)
[-- Attachment #2: Type: text/html, Size: 2018 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packaging OCaml repositories that define multiple packages?
2023-01-08 15:17 ` Julien Lepiller
@ 2023-01-08 19:52 ` Csepp
2023-01-09 1:37 ` Csepp
0 siblings, 1 reply; 6+ messages in thread
From: Csepp @ 2023-01-08 19:52 UTC (permalink / raw)
To: Julien Lepiller; +Cc: Csepp, Guix Devel, pukkamustard
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packaging OCaml repositories that define multiple packages?
2023-01-08 19:52 ` Csepp
@ 2023-01-09 1:37 ` Csepp
2023-01-09 7:17 ` pukkamustard
0 siblings, 1 reply; 6+ messages in thread
From: Csepp @ 2023-01-09 1:37 UTC (permalink / raw)
To: Julien Lepiller; +Cc: Csepp, Guix Devel, pukkamustard
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packaging OCaml repositories that define multiple packages?
2023-01-09 1:37 ` Csepp
@ 2023-01-09 7:17 ` pukkamustard
2023-01-09 12:07 ` Csepp
0 siblings, 1 reply; 6+ messages in thread
From: pukkamustard @ 2023-01-09 7:17 UTC (permalink / raw)
To: Csepp; +Cc: Julien Lepiller, Guix Devel
Csepp <raingloom@riseup.net> writes:
> But there are packages that were added by others that already specify
> which subpackage they build, and yet seem to be accepted as subpackages.
Do you have an example?
And maybe send in your patches, that may provide more context around
this discussion.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Packaging OCaml repositories that define multiple packages?
2023-01-09 7:17 ` pukkamustard
@ 2023-01-09 12:07 ` Csepp
0 siblings, 0 replies; 6+ messages in thread
From: Csepp @ 2023-01-09 12:07 UTC (permalink / raw)
To: pukkamustard; +Cc: Csepp, Julien Lepiller, Guix Devel
pukkamustard <pukkamustard@posteo.net> writes:
> Csepp <raingloom@riseup.net> writes:
>
>> But there are packages that were added by others that already
>> specify
>> which subpackage they build, and yet seem to be accepted as
>> subpackages.
>
> Do you have an example?
>
> And maybe send in your patches, that may provide more context around
> this discussion.
I submitted them last night, but only 13 out of the 39 got acknowledged.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;include=originator%3Acsepp
The one with the aliases is among the unacknowledged ones.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-09 12:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-08 14:04 Packaging OCaml repositories that define multiple packages? Csepp
2023-01-08 15:17 ` Julien Lepiller
2023-01-08 19:52 ` Csepp
2023-01-09 1:37 ` Csepp
2023-01-09 7:17 ` pukkamustard
2023-01-09 12:07 ` Csepp
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.