* 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.