This should be unnecessary as opam already installs <pkg>.install by default (on top of the install section)

Thanks. I just tested removing this line with esy, and esy does not install dream.install by default, causing a dependency error later if the line is removed. This may be a bug/oversight, but it's non-obvious and I think it's better not to rely on the repository client interpreting it correctly. So, I prefer to keep this line.

Hopefully, this whole install: section will become unnecessary relatively soon, and I'll remove it completely in a future Dream release.

One last question (from me) before merging. This may be a good opportunity to try how the vendoring behaves. Have you checked what happens if you install dream and then install the opam version of any of its vendored dependencies separately (or if you have some of the vendored dependencies preinstalled when you compile it)?

Thanks. I just tested removing this line with esy, and esy does not install dream.install by default, causing a dependency error later if the line is removed.

Sorry, dumb question, have you tried removing the whole install section or just that line?

One last question (from me) before merging. This may be a good opportunity to try how the vendoring behaves. Have you checked what happens if you install dream and then install the opam version of any of its vendored dependencies separately (or if you have some of the vendored dependencies preinstalled when you compile it)?

Yes, assuming you are asking about opam as the client. Because of the conflicts: section, opam shows prompts like this:

The following actions will be performed:
  ⊘ remove  dream  ~dev* [conflicts with httpaf]
  ∗ install httpaf 0.7.1
===== ∗ 1   ⊘ 1 =====
Do you want to continue? [Y/n]

have you tried removing the whole install section or just that line?

I removed just that line during this PR. The section itself exists because depending on dream fails without it (when the vendored packages are missing), which I experienced when I first tried to install dream after vendoring these deps. I also tried variations of dune install -p ... (as suggested by @kit-ty-kate, thank you) and (vendored_dirs). However, dune install -p did not seem to be able to actually find the vendored packages' .install files when used on its own. (vendored_dirs) disallows passing -p options for selecting subpackages of vendored packages, which forces an overestimation of their deps that are needed for dream, since they are monorepos, pulling in e.g. async via httpaf-async.

So, AFAIK, opam-installer is the only thing that works right now (apart from hacky manual scripts). I've been implicitly testing with opam-installer for several weeks now.

(vendored_dirs) disallows passing -p options for selecting subpackages of vendored packages, which forces an overestimation of their deps that are needed for dream, since they are monorepos, pulling in e.g. async via httpaf-async.

And to clarify this, the failure is during the build of dream itself, since it picks up false transitive dependencies like async, which are not installed (and shouldn't be, on a request for dream only). So I don't know if dune install together with (vendored_dirs) would work, because (vendored_dirs) forces a failure during build, before the install step. EDIT: To the best of my knowledge.

BTW, since you made most of the Piaf dependency choices (my forks of http/af and websocket/af, lwt_ssl, etc), you could depend on Piaf and its vendored libs (piaf.httpaf, piaf.h2, etc).

Then you'd just need to vendor websocket/af and e.g. use a subdir stanza like I do in Piaf

I may well do that eventually. However, I understand that then Dream will be "locked" to whatever exact commits Piaf is vendoring, is that right? At this early point, I still need the flexibility to choose other commits, but I hope to streamline that away soon.

Thanks for the subdir stanza tip.

Thanks for the explanations, indeed one reason I was asking was due the presence of those conflicts. Thanks for clarifying the issue. It is a pity that it does not install cleanly due to the vendoring

Do you mean in the context of a switch with those packages? It seems to install cleanly otherwise. The vendoring is a temporary situation. My goal is to eliminate it relatively quickly. I think it's fine for a first release — this isn't affecting any users of Dream, because it mostly doesn't have any. It will just be a temporary annoyance for early adopters.