Giters

tarides / opam-monorepo

Assemble dune workspaces to build your project and its dependencies as a whole

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Monorepo / switch hybrid opam file

TheLortex opened this issue · comments

commented

Hi, thanks for all the work on opam-monorepo 0.3.

I have been able to implement the changes in the Mirage tool, but there are some changes that would simplify the patch.

Basically, what we want to do is:

  • have a single opam file for switch and monorepo dependencies
  • lock and pull that file using opam-monorepo
  • install the switch dependencies using opam on the opam file

It's a bit different from the current workflow:

  • have a single opam file for switch and monorepo dependencies
  • lock and pull that file using opam-monorepo
  • install the switch dependencies using opam on the lockfile

The problem is that the lockfile is not opam-installable as opam-overlays is temporarily added, so +dune packages are not available.
By using a variable in the opam file I'm able to let opam only install the switch dependencies:

depends: [
  "lwt" {switch != "__opam__"}
  "mirage-bootvar-solo5" { >= "0.6.0" & < "0.7.0" & switch != "__opam__" }
  "mirage-clock-solo5" { >= "4.2.0" & < "5.0.0"  & switch != "__opam__"}
  "mirage-logs" { >= "1.2.0" & < "2.0.0"  & switch != "__opam__"}
  "mirage-runtime" { >= "4.0" & < "4.1.0" & switch != "__opam__"}
  "mirage-solo5" { >= "0.8.0" & < "0.9.0" & switch != "__opam__"}
  "mirage" { build & >= "4.0" & < "4.1.0" }
  "ocaml" { build & >= "4.08.0" }
  "ocaml-solo5" { build & >= "0.8.0" }
  "opam-monorepo" { build & >= "0.2.6" }
]

opam-monorepo works as usual. opam install works by passing the OPAMVAR_switch="__opam__" environment variable.

What do you think about this issue ?

The principle we want to apply in Mirage is to modify the opam switch as less as possible. That's why opam-overlays is only temporarily added while the lock step happens. Do you think that's still a sensible thing to do ?

commented

It all sounds good to me! I think that it might cause problems in some cases as opam might not agree on dune and ocaml versions with the lockfile when installing those extra packages but besides that, since it require no extra solver run or anything from opam-monorepo, I have no objection to that workflow!

You could eventually generate the lockfile first and then ask opam to install the lockfile and the source file. That way you would have a solution that works for both the vendored packages and the opam installed ones.

commented

Would be fixed by #316, closing as a duplicate.