Stop opam package installation when a package install fails

[MisterDA]

Hi everyone,
I'm installing in a container a forest of dependencies with opam install -y --deps-only --with-test .. However, one of the dependencies fails to build. It super useful on an end-user device to keep building and installing packages, because each installed package is a win, but not so much when working with (e.g., Docker) containers: the command will fail and the cache layer will be discarded anyway.
It seems that there is no way to short-circuit the install as soon as one of the dependencies fails to be installed. Adding one would help saving time and energy in containers!
As suggested by a skilled hacker, one could (as a workaround?) monitor the subprocesses for failure and kill all remaining opam instances.
Although a bit early, I'd suggest a variation on "fail fast" for the name of this option (by analogy with CI terminology), another Opam ninja prefers --stop-on-error.

[dra27]

I don't think opam should get into the business of trying to kill sub-processes when an error has been detected (this is likely to be a stability disaster on Windows), but it should be easy enough to be able to tell the scheduler to stop issuing new jobs after an error has been detected. A marginally more complicated, but possibly useful extra, would be to be able to mark "stop" points in the graph - in particular, having successfully executed "Build foo.x", it is wasted effort not to continue to "Install foo.x".

[MisterDA]

I don't think opam should get into the business of trying to kill sub-processes when an error has been detected (this is likely to be a stability disaster on Windows)

How would that be different from the user force-stopping opam, e.g., by sending SIGINT signals on the process?

A marginally more complicated, but possibly useful extra, would be to be able to mark "stop" points in the graph - in particular, having successfully executed "Build foo.x", it is wasted effort not to continue to "Install foo.x".

In what case would that be useful? On an end-user system, (if I'm not mistaken) the overall build process isn't stopped in case of an error so the "Install foo.x'' is always executed, and on a container system, if the whole install is executed as a single command it is wasted effort to continue.

[dra27]

I don't think opam should get into the business of trying to kill sub-processes when an error has been detected (this is likely to be a stability disaster on Windows)

How would that be different from the user force-stopping opam, e.g., by sending SIGINT signals on the process?

That's unreliable too, that's why I don't want to bake it in!

A marginally more complicated, but possibly useful extra, would be to be able to mark "stop" points in the graph - in particular, having successfully executed "Build foo.x", it is wasted effort not to continue to "Install foo.x".

In what case would that be useful? On an end-user system, (if I'm not mistaken) the overall build process isn't stopped in case of an error so the "Install foo.x'' is always executed, and on a container system, if the whole install is executed as a single command it is wasted effort to continue.

The option's not just useful for containers! The wasted effort for the install is (usually) very low; that's not true of the build.

[avsm]

As suggested by a skilled hacker, one could (as a workaround?) monitor the subprocesses for failure and kill all remaining opam instances.

To be clear, the skilled hacker's comment about this workaround were in jest ;-)

[Niols]

I would very much like such an option with the same use case in mind: containerisation and CI. Actually, I would use it from time to time on my local machine, when I'm trying to install a package in particular but already know I'm going to roll back my OPAM packages anyways in case of failure. I suppose avoid issuing new jobs would already be a good thing indeed. I like --fail-fast, mostly because I've seen it in some other package managers.