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.24k stars 353 forks source link

Sort `opam upgrade` output by semver(-ish) versioning breakdown: major, non-major #5288

Open ELLIOTTCABLE opened 2 years ago

ELLIOTTCABLE commented 2 years ago

At the moment, the output of an opam upgrade can be somewhat overwhelming on a large project.

When analyzing this before pressing y, I find myself overwhelmingly doing one thing: comparing version numbers.

A computer is a lot more efficient, and less error-prone, at checking version numbers. :P

I propose that the summaries of actions-to-take (if larger than some threshold 𝑛) group their output first by lose semver assumptions, before display to the user:

The following actions will be performed:
Major (or beta-minor) version changes:
  β‡— upgrade   conf-libcurl                1 to 2
  βˆ— install   merlin-lib                  4.6-414                      [required by dot-merlin-reader]
  β‡— upgrade   redis                       0.5 to 0.6
  β‡— upgrade   eqaf                        0.8 to 0.9
  β‡— upgrade   rpclib                      8.1.2 to 9.0.0
  β‡— upgrade   redis-lwt                   0.5 to 0.6
  β‡— upgrade   sedlex                      2.6 to 3.0
  βˆ— install   icalendar                   0.1.6                        [required by <... snip ...>]
  β‡— upgrade   sqlgg                       20220401+git to 20220831+git
  β‡— upgrade   ppx_deriving_rpc            8.1.2 to 9.0.0

Minor and patch changes:
  β†— upgrade   ocamlfind                   1.9.3 to 1.9.5
  β†— upgrade   omake                       0.10.3 to 0.10.5
  β†— upgrade   xdg                         3.1.0 to 3.2.0
  β†— upgrade   sexplib0                    v0.15.0 to v0.15.1
  β†— upgrade   re                          1.10.3 to 1.10.4
  <... snip ...>
  β†— upgrade   ca-certs                    0.2.2 to 0.2.3
  β†— upgrade   conduit-lwt-unix            5.1.0 to 5.1.1
  β†— upgrade   aws-s3                      4.6.0 to 4.7.0
  β†— upgrade   aws-s3-lwt                  4.6.0 to 4.7.0

No-op recompilations:
  ↻ recompile ocaml-base-compiler         4.14.0                       [upstream or system changes]
  ↻ recompile ocaml-config                2                            [uses ocaml-base-compiler]
  ↻ recompile ocaml                       4.14.0                       [uses ocaml-base-compiler]
  ↻ recompile seq                         base                         [uses ocaml]
  <... snip ...>
  ↻ recompile ppx_jane                    v0.15.0                      [uses dune]
  ↻ recompile int_repr                    v0.15.0                      [uses dune]
  ↻ recompile base_bigstring              v0.15.0                      [uses dune]
  ↻ recompile core                        v0.15.0                      [uses sexplib, jst-config, dune]
  ↻ recompile core_kernel                 v0.15.0                      [uses dune]
  ↻ recompile re2                         v0.15.0                      [uses dune]
===== βˆ— 2   ↻ 238  β‡— 8   β†— 45 =====
Do you want to continue? [Y/n]

To anticipate some feedback and agree with it β€” this feature is a footgun, if the OCaml ecosystem isn't reasonably careful as a whole about our semver. My recollection is of there being some pushback and 'who cares' about semver a few years ago, last time I read anything on this topic; but it does seem to have gained some additional support β€” and fwiw, @Khady has convinced me to open this issue anyway. πŸ˜…

kit-ty-kate commented 2 years ago

Which version of opam are you using? Have you tried with opam master? (see https://github.com/ocaml/opam/pull/5045)

ELLIOTTCABLE commented 2 years ago

Hm, that seems almost like … the opposite of this?

Well, not quite, on second glance β€” but the important part here is definitely the semver-analysis, not the sorting out of recompilations or installations

kit-ty-kate commented 2 years ago

Thinking about it again, it seems rather "easy to do" on top the current code. Essentially you’re just asking for the new upgrades <n> packages section to be split into two:

We’ve talked about in the dev meeting and we’d be happy to review a PR for that if you have time to make one.