Fix non-interactive behavior for opam-monorepo depext
#216
Conversation
There was a problem hiding this comment.
It looks good! It seems right to ask for confirmation before installing packages.
Does the opam mention of the to be run sudo command appears when running this? If not it might be worth also mentioning this in the prompt.
Could you explain how that fixes #212 though as it isn't entirely clear to me where the bug was coming from.
Besides that I have a couple comments and we need a changelog entry!
It seems that |
|
I've tried to address all your comments. When you are happy with the changes I'll squash my commits. |
So you want me to continue to see ugly backtraces? :p I'll revert this for now, but I think it's a common behaviour with interactive scripts. |
samoht
changed the title
opam-monorepo depextopam-monorepo depext
|
Rebased and squashed. |
CHANGES: ### Added - Add a list subcommand to list the duniverse packages in the lockfile (tarides/opam-monorepo#217, @samoht) ### Changed - Only warn users about missing dune-ports repo in OPAM switch if no solution can be found due to packages not building with dune (tarides/opam-monorepo#210, @Leonidas-from-XIV) - Rename the `--repo` option to `--root` to make it more straightforward that this is referring to the project root (tarides/opam-monorepo#218, @samoht) - Improve the wording of the lockfile selection log (tarides/opam-monorepo#222, @NathanReb) - Display the full solver error with `--verbose` (tarides/opam-monorepo#229, @emillon) ### Fixed - Better errors for `opam-monorepo depext`, especially for non-interactive shells (tarides/opam-monorepo#216, @samoht) - Properly detect all opam packages defined in the current repository, preventing it from later pulling duplicates into the duniverse if they were part of the target packages dependencies. (tarides/opam-monorepo#203, @Leonidas-from-XIV) - Properly report missing dune-project file when trying to determine the to-be-genrated lockfile name (tarides/opam-monorepo#227, @NathanReb)
Fixes #212