In the context of releasing 0.0.22 on opam-repository the PR showed some CI issues. See here.
I am thinking now about the potential impact of that dependency to future submission of packages depending on volgo.
Say a subsequent package A were to depend on one of the volgo hg packages H, and as set by H's opam file, H package has conf-hg {with-test} in its dependencies. I don't know if the opam-repository CI for A's submission will include the tests deps of its transitive dependencies? (And inherit's H's conf-hg here).
I would like to get a feel for whether we'd be better off dropping the conf-hg {with-test} dependency, if this were to affect all dependents of these packages. Given the tests of dependents won't actually run any code that ends up calling the hg executable, we could decide to let users deal with it dynamically when using the package rather than installing it in --with-test mode.
I'm not sure, opening this ticket to track that idea / proposal.
In the context of releasing
0.0.22on opam-repository the PR showed some CI issues. See here.I am thinking now about the potential impact of that dependency to future submission of packages depending on volgo.
Say a subsequent package A were to depend on one of the volgo hg packages H, and as set by H's opam file, H package has
conf-hg {with-test}in its dependencies. I don't know if the opam-repository CI for A's submission will include the tests deps of its transitive dependencies? (And inherit's H's conf-hg here).I would like to get a feel for whether we'd be better off dropping the
conf-hg {with-test}dependency, if this were to affect all dependents of these packages. Given the tests of dependents won't actually run any code that ends up calling the hg executable, we could decide to let users deal with it dynamically when using the package rather than installing it in--with-testmode.I'm not sure, opening this ticket to track that idea / proposal.