expose the transitive opam dependencies of a project #151
Conversation
|
You seem to be inferring the opam package from the ocamlfind dependencies. That's completely wrong, you shouldn't do that. Infer the opam dependencies using opam! ocamlfind and opam packages are only |
|
@Drup thanks for your feedback. I find your choice of words insulting ("completely wrong", "you shouldn't do that") -- I'm open for constructive feedback, but not for insults. As the build process of MirageOS goes: it calls On the other hand a user looks at opam packages (including their version numbers and dependencies), and is interested in these releases, rather than ocamlfind. This is why we end up having to map ocamlfind libraries and version numbers to opam packages, and this PR is an attempt at that. "use the appropriate tools" well, please educate me what are the appropriate ones. As mentioned above, I don't think requiring opam2 is an option for now. We should keep in mind what is the current state, what is the goal, and how to get there!? I don't think the current state (released functoria) is of much use for the cases outlined above (reproducibility, figuring out whether a recompilation is required), and this PR improves this information, but does not yet reach the goal. Other inconsistencies I just noticed include |
|
I'm sorry if you feel insulted, that was not my intention, but I don't feel like I have been particularly mean or anything. But trying to map ocamlfind to opam packages by name is doomed to fail. The current ecosystem is far too irregular for that. You might aim to make the ecosystem more regular, and I would agree, but that's a long term battle, not something you can rely on now. The command line I gave you is for opam2 simply because that's what I have installed. :) @AltGr Do you have a proposition to fetch all the installed non-build recursive dependencies of some currently-installed packages that is compatible with 1.2 ? With their installed depopts ? |
not per se, but And there is the obvious:
No. |
|
Yeah, I proposed the "obvious" above.
😞 Second attempt: we can fetch all the deps in 1.2 easily. Would it be possible after the fact to know which one are build (using some script, if necessary) ? |
|
opam 1.2 already has json output, although less complete, so it could probably extracted from that, yes. |
|
now that we require opam2, I rebased this PR to use opam2! :) feedback is welcome (for pinned packages, the output is a bit uninformative atm (only displays version number), would be nice to get the source-hash, ref ocaml/opam#3675). I convinced myself that the build vs runtime dependencies is not crucial. @Drup what do you think about this revised PR? |
app/functoria_app.ml
Outdated
| pp_libraries (Info.libraries i) | ||
| module_name name | ||
| pp_packages (List.sort String.compare (String.Set.elements pkg)) | ||
| pp_libraries (List.sort String.compare (String.Set.elements libs)) |
There was a problem hiding this comment.
According to the doc, Set.elements is guaranteed to be sorted. You could either remove the sorting, or remove the transformation to a set.
There was a problem hiding this comment.
fixed in 520079e (removed List.sort String.compare)
CHANGES: * compute all transitive opam dependencies for info (mirage/functoria#151, by @hannesm) * support pin-depends in generated opam file (mirage/functoria#163, by @hannesm) * use dune as build system (mirage/functoria#158, by @emillon) * use Ptime for time printing (mirage/functoria#160, by @emillon) * inject global arguments into generated header (mirage/functoria#159, by @emillon) * add Functoria_key.add_to_context (mirage/functoria#161, by @emillon) * output opam2 files (mirage/functoria#157, by @hannesm)
the current state is that the explicitly named opam dependencies are gathered in
Functoria_info. While this is useful for building a unikernel, at runtime it is much more convenient to have a complete list of all runtime dependencies (maybe even including build time dependencies) available. One use case is to be able to poke at a unikernel image and discover whether it needs to be updated (given a new stream of released libraries). Another use case is to be able to reproduce a unikernel just from a binary (this requires to includecc,ld, andasversion information - but not more AFAICT, maybeCFLAGSset in the environment).The approach taken here uses
ocamlfind query -r -format %pduring build, and usingopam substafterwards to replace the version numbers with the installed opam packages.Drawbacks:
opamcommand line to get this information, that'd be great --opam repo listis rather incomplete and not too useful)ocamlfindis incomplete (since it usesocamlfinddependencies, as specified inMETA, which is incomplete -- e.g. there's no mention ofocaml-freestandinginmirage-solo5,bigarrayrequiresunix,gmp-xen/gmp-freestandingdon't appear in any dependency chain, and I can't find anyocaml-srcdependencies anywhere)ppxat version X may generate different output than at version Y. I'd prefer to separate the build and runtime dependencies though (whereasopam list --recursive --resolve=tcpipdoesn't distinguish between the two).Previous discussion at mirage/mirage#896 where (a) @avsm mentions the need for the opam repositories, (b) @samoht points to https://github.com/MagnusS/mirage-stats-demo/blob/master/manifest/manifest.ml for earlier work (using
opam list -s --required-by %s --rec --depopts --installedwhich includes build dependencies AFAICT), (c) @Drup suggests to use opam2:opam list --nobuild --depopts --installed --rec --required-by <PKG>- but I don't think that relying on opam2 is an option atm.