search

ocaml / opam

opam is a source-based package manager. It supports multiple simultaneous compiler installations, flexible package constraints, and a Git-friendly development workflow.
https://opam.ocaml.org
Other
1.25k stars 364 forks source link

Stop opam package installation when a package install fails #4629

Open MisterDA opened 3 years ago

MisterDA commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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.