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.23k stars 351 forks source link

make dry-run also print install commands #1142

Closed agarwal closed 10 years ago

agarwal commented 10 years ago

Currently, with opam 1.1.0, we have:

$ opam install --dry-run biocaml
The following actions will be performed:
 - install biocaml.pinned
1 to install | 0 to reinstall | 0 to upgrade | 0 to downgrade | 0 to remove
Dry run: exiting now.

This isn't all that helpful. It would be nice if at least the install commands would get printed out. For example, I really want this output:

$ opam install --dry-run -d -t biocaml
The following actions will be performed:
 - install biocaml.pinned
1 to install | 0 to reinstall | 0 to upgrade | 0 to downgrade | 0 to remove

=-=-= Installing biocaml.pinned =-=-=
biocaml.pinned Synchronizing with /Users/ashish/code/biocaml
Building biocaml.pinned:
  omake -j2 PREFIX=/Users/ashish/.opam/4.01.0 COMPILE_LIB_LWT=true COMPILE_LIB_ASYNC=true COMPILE_APP=true COMPILE_TESTS=false COMPILE_BENCHMARKS=false
  omake install
Building and running the test:
  omake -j2 PREFIX=/Users/ashish/.opam/4.01.0 COMPILE_TESTS=true COMPILE_APP=false
Generating the documentation:
  omake -j2 doc
  omake install_doc DOCDIR=/Users/ashish/.opam/4.01.0/doc
Dry run: exiting now.

This shows me how the variables get expanded, which is quite helpful.

dbuenzli commented 10 years ago

Very marginally related (but maybe should be thought toghether) to https://github.com/ocaml/opam/issues/562.

smagill commented 10 years ago

Seconded. This would be very useful.

agarwal commented 10 years ago

Can you explain the difference between --dry-run and --show.

AltGr commented 10 years ago

I'm open to ideas for better wording of --show

dbuenzli commented 10 years ago

@AltGr try to mimick other tools. I'm not sure but isn't for example in apt-get, --dry-run what we had before ? That is what the tool would output but without the side effects being performed.

Why not just do it like before and if there's one more option then print all the commands. E.g.

opam install --dry-run # as before 
opam install --dry-run --detailed # print the details 
agarwal commented 10 years ago

I think the new behavior of --dry-run is the only one that is useful. The less detailed (current) behavior provides almost no information. If you do want both levels of detail, I'd go with @dbuenzli's suggestion.

samoht commented 10 years ago

well I found the previous behavior of --dry-run quite useful to see which actions would be executed by the command.

Or, using Daniel's suggestion, we can maybe have opam install --dry-run --verbose to have more details.

dbuenzli commented 10 years ago

Yes of course --verbose, I thought --verbose was the output of --debug.

AltGr commented 10 years ago

I'm not sure I was perfectly understood. apt-get install --dry-run is closer to the new --dry-run, although they don't print all actions because they would need to download packages for that.

The only difference now is that --show will stop after printing the summary of actions while --dry-run will continue, still without performing anything of course. I am pretty confident that this is a more standard behaviour for --dry-run and it's what @agarwal asked for. It doesn"t really feel like just a difference in verbosity either...

AltGr commented 10 years ago

@agarwal the previous behaviour (now that of --show) is very useful for opam upgrade for example.

dbuenzli commented 10 years ago

I still think the naming is not very clear:

opam install pkg --dry-run  # this is clear 
opam install pkg --show     # this doesn't make it clear that it will be a dry run
agarwal commented 10 years ago

@AltGr I don't see why it's not a difference in verbosity. If the behavior of --show is like the first output in my original post, and the new --dry-run is like the second output, then we see the second has everything of the first plus more. Thus, I'd consider the second more verbose than the first.

Maybe the problem is I still don't see the benefit of --show. It only lists the number of packages that will be installed, reinstalled, etc. It might be useful if it at least provided the names of the packages. Fine if others find it useful, but I agree with @dbuenzli that --show is not intuitive. It doesn't tell you what will be shown.

AltGr commented 10 years ago

Yes, I wasn't happy with the naming --show to begin with, hence my original question. It does, however, list all the installations/removal/reinstaillation/upgrades/downgrades that would be performed and on which packages, and the reasons for these actions, which is pretty useful. What it doesn't do is go through the actual commands performing these actions. Eg (latest version, I've just improved the reasons and display):

[lg@agaric ~/ocamlpro/opam]% opam install core_kernel --show
The following actions will be performed:
 - upgrade   type_conv.109.60.00 to 109.60.01      [required by variantslib, sexplib, bin_prot, fieldslib, typerep]
 - upgrade   utop.1.10 to 1.11
 - upgrade   mstruct.1.2.0 to 1.3.0
 - upgrade   pipebang.109.60.00 to 110.01.00       [required by core_kernel]
 - upgrade   cmdliner.0.9.2 to 0.9.4               [upstream changes]
 - upgrade   variantslib.109.15.02 to 109.15.03    [required by core_kernel]
 - upgrade   sexplib.109.60.00 to 110.01.00        [required by core_kernel]
 - recompile pa_ounit.109.53.02                    [uses type_conv]
 - recompile ocaml-data-notation.0.0.11            [uses type_conv]
 - upgrade   fieldslib.109.20.02 to 109.20.03      [required by core_kernel]
 - recompile dyntype.0.9.0                         [uses type_conv]
 - recompile deriving-ocsigen.0.5                  [uses type_conv]
 - recompile comparelib.109.60.00                  [uses type_conv]
 - install   bin_prot.109.53.03                    [required by core_kernel]
 - recompile opam-lib.1.1.1                        [uses cmdliner]
 - recompile ocp-indent.1.4.1                      [uses cmdliner]
 - recompile uri.1.3.13                            [uses sexplib]
 - recompile pa_bench.109.55.02                    [uses type_conv]
 - recompile oasis.0.4.1                           [uses ocaml-data-notation]
 - recompile js_of_ocaml.1.4.0                     [uses deriving-ocsigen]
 - install   typerep.109.55.02                     [required by core_kernel]
 - recompile ocp-index.pinned                      [uses cmdliner]
 - recompile opamfu.0.1.1                          [uses uri]
 - recompile cow.0.9.1                             [uses type_conv, uri]
 - recompile cohttp.0.9.16                         [uses sexplib, fieldslib]
 - recompile ocaml-zmq.0.3.2                       [uses oasis]
 - install   core_kernel.110.01.00
 - recompile github.0.7.0                          [uses uri, cohttp]
 - recompile iocaml.0.3.0                          [uses ocaml-zmq, ocp-index]
3 to install | 18 to reinstall | 8 to upgrade | 0 to downgrade | 0 to remove

Actually now that the "confirmation" issue is fixed, this is less needed though. Thinking about it, --no would make perfect sense :D

dbuenzli commented 10 years ago

Why not --show-actions then or even --show-actions-only (remember you can always specify a prefix).

agarwal commented 10 years ago

I finally think --show is useful. Thanks! Everyone has been referring to the package installations as actions, and somehow knew that the build commands of a package are not actions. That actually confused me during this thread, so I'm unsure if --show-actions will be very clear to others. Well worded documentation might be the easy fix.