<sterni>
are there any plans on changing dependency resolution for MirageOS 4?
<sterni>
i. e. will we in the future compile and run some code to find out on which packages a unikernel actually depends for a given target?
<sterni>
I'm guessing it is gonna stay this way as the resolution seems somewhat complex
<hannes>
sterni: (I'm not an expert on this topic) MirageOS4 will use "opam-monorepo" (https://github.com/ocamllabs/opam-monorepo/) for creating a monorepo for each unikernel (i.e. after the "mirage configure" step)
<hannes>
~> it is still "mirage" (the tool) embedding the packages required, and opam (the solver and repository) providing packages. but AFAIK the "each configured MirageOS unikernel is an opam package" will no longer hold.
<sterni>
interesting, that could be better than the current situation for me possibly
<sterni>
I've had some motivation once again to work on building unikernels with nix and currently trying to get the xen target to work
<sterni>
and I was wondering if there could be possibly good UX in nix for packaging unikernels as well
<sterni>
at least for nixpkgs we can't really run mirage configure and then pull in all needed packages
<sterni>
(due to self imposed restrictions)
<sterni>
so it is not ideal as you basically end up rebuilding until you've figured out all depnedencies and then when you switch target the list is very different
<sterni>
probably solving this in a nice way would require reimplementing mirage configure in nix which is not something that seems all that wise
<hannes>
sterni: basically, with nix, you want a static set of inputs (tarballs, git commits, ..) that you download during the fetch phase, and then you're building in a separate step (not connected to the network) ?
<sterni>
hannes: exactly
<sterni>
with the opam monorepo thing we could possibly move this into the fetch phase if it is deterministic
<hannes>
sterni: I have some setup for reproducible MirageOS builds, what I do there is to use the opam file from "mirage configure -t hvt" -- thus there's only a single target.
<hannes>
Indeed with "monorepo" and also "moving target-specific packages into a single, and variants", this should be possible
<hannes>
i.e. think of a mirage-net abstract interface, and the same codebase (repository / opam package) provides implementations for the different targets [this is only possible once the switch to use dune in MirageOS is done, which is the major motivation for 4.0]
<hannes>
the remaining issue will be "mirage-unix / mirage-solo5 / mirage-xen" -- but tbh I cannot see a reason not to combine them using variants as well.
<sterni>
those are not that much trouble I think because you always need them right?
<sterni>
I already have a switch which pulls in the correct one of those depending on target
<sterni>
the issue is rather stuff like mirage-clock where I don't know really if a specific unikernel will need it, but if it needs it I need to choose a different package depending on target
<sterni>
a solution to make it more convenient could be to run mirage configure once and then generate the package expression from the opam file
<sterni>
but since that is not gonna stay exactly, I'll just reevaluate with mirageos 4 :)
<hannes>
(sorry, variants were the now-removed-thing, but virtual libraries IIRC could solve that specific issue (plus allow us to unify code bases (and share code) and remove opam packages)
<sterni>
for virtual libraries are all implementations then shipped in the same package?
<hannes>
yes (AFAIK, I'm not an expert on this), with variants this was allowed to span across packages (but here semantics are tricky, and in the end this was reverted)
<sterni>
i see, yeah that would be really nice
<hannes>
it would as well make the mirage utility less magic
<sterni>
indeed yeah and ideally the having the same set of packages as inputs would work for all targets (apart from maybe mirage-{unix,xen,...})
<hannes>
well, I'd be in favor to unify these into a single "mirage-platform" (with a shared interface across targets) and using variants as well there... likely the opam-dependencies would be a union of all targets (e.g. tuntap would be required), but in the "build" step only those packages needed for the specific target would be built.
<sterni>
yeah that'd be good as well
<sterni>
as long as we'll have static linking for the unix target in mirageos 4 so we don't need the complete package at runtime as well
<hannes>
and then it's only a small step for multi-target binaries ;)
<hannes>
yes - my impression is that getting 4.0 out of the door is pressing, and the whole virtual library usages will need to wait a few more weeks
<sterni>
wait the xen target needs to run opam currently?
<sterni>
I'm guessing opam config var prefix is for pkg-config