[opam-devel] ows reports

[Fabrice Le Fessant]

On Thu, Oct 2, 2014 at 11:25 AM, Thomas Gazagnaire
<thomas at gazagnaire.org> wrote:
>>  I don't think this is going to work: red boxes in OWS have a clear
>> semantics, from the user point of view, it means that 'opam list' is
>> going to show the package with the corresponding version as available
>> for the current switch, but 'opam install PACKAGE.VERSION' is going to
>> fail. That's bad user experience. Changing the red box into an orange
>> box is not going to change this bad experience for the user.
>
> Then the table is inconsistent:
>
> $ opam install typerex.1.99.6-beta
> [ERROR] typerex.1.99.6-beta is not available because it requires OCaml < 4.02.0.
>
> opam returns an error, but the box is "white" on ows. Following your logics, it should be "red".

─lefessan at peerocaml [~]
╰─➤ opam switch 4.02.0                                                  [11:36]
# To setup the new switch in the current shell, you need to run:
eval `opam config env`

╰─➤ opam list --all | grep typer                                        [11:36]
typerep                   --  typerep is a library for runtime types.
(no typerex here)

╰─➤ opam install typerex.1.99.6-beta                                    [11:36]
[ERROR] typerex.1.99.6-beta is not available because it requires OCaml < 4.02.0.

Why is it inconsistent ? It is not listed in "opam list --all" for 4.02.0.

More strangely:
╰─➤ opam search typerex                                                 [11:44]
# Existing packages for 4.02.0:
ocaml-top     --  The OCaml interactive editor for education
ocp-indent    --  A simple tool to indent OCaml programs
ocp-index     --  Lightweight documentation extractor for installed OCaml librar
spotinstall   --  A tool to facilitate the installation of OCaml annotation file
typerex       --

Here, typerex is listed, even though it is explicitely written in its
opam file that is cannot be installed on 4.02.0 (it is a bug in my
opam version, probably). I must say I am a bit puzzled by the output
of "opam list --all", it seems to not display some packages like
"js-lz4", although they are said to be available for 4.02.0 (but
broken in OWS).

> Usually users request a package name, not a specific version of a package. ows doesn't make the difference between "all versions are broken" and "the version X is broken" which is a far worst user experience.

You would like to have a red box on the package itself when all
versions are broken ? Indeed, it is a good idea.

> Now, from a repository maintainer point-of-view, if someone creates a new metrics and advertises it by saying "look how bad it is",

Are you saying that somebody at IRILL used OWS to complain about the
quality of the opam-repository ? I only remember it being advertised
as a complementary way to improve the quality of the repository, not
as a way to disqualify its maintainers.

> I guess the goal is to make some changes (the policy, the workflow, ...) to improve the metrics results or at least to propose or explain how it can be improved -- if not, I don't see the point. Currently, it is still unclear to me how we (the repo maintainers) can fix all the "broken" packages on the repo without requiring all packages to compile on all the versions of the compiler (which will never happen) or by duplicate metadata (the transitive closure of the available fields) which will get out-of-sync quickly.

Currently, the field "ocaml-version" is used to tell that the
"content" of the package is incompatible with a given OCaml version.
Maybe there should be another field to say that the package is known
to be incompatible with a given ocaml version, because of missing
dependencies. This way, it would not be printed in the list of
available packages for that version. OWS could test for packages which
are said to be unavailable because of missing dependencies, and become
available when a dependency is fixed, so that the repo maintainers can
immediatly update the status to make it available again in OPAM.

Note that you are touching a problem of the github workflow, the fact
that the maintenance of the repository relies on a small set of
volunteers, when in Debian, for example, every package is maintained
by its own maintainer, who is responsible to fix the problems.

>>  Moreover, the reasons for a failure may me mixed: if package A
>> depends on B, and there are two versions of B, one depending on C with
>> a version of C that does not exist, the other one with a version of C
>> that is not available for the current compiler, what would be the
>> reason for A not being installed ? Something has to be done, either
>> adding a new version of C, or porting the old version of C on the
>> current compiler, maybe adding a new version of B, or dropping the
>> dependency on B for A, but whatever it is, OWS is not going to give an
>> advice. It will just say "A is broken" and put a red box.
>
> These are the interesting packages which should be brought to attention to the maintainers. Not the other 99% of packages which are unavailable by transitivity (and reported as such by opam), especially when a more recent version of this package exists and fix the availability issue.

I was talking about a specific version of A, not all versions of A.

>>  Actually, it would be nice to run `distcheck` twice for every new
>> pull-request: once to compute the number of broken packages before the
>> commit, and once to compute the number of broken packages after the
>> commit. This way, only pull-request decreasing the number of broken
>> packages would be accepted. This could be part of a general
>> `opam-repo-lint` tool, that would also verify that every package
>> description is smaller than 50 kB (ref. Coccinelle), and call
>> `opam-lint` on every `opam` file.
>
> Any tool to help us triaging incoming pull-requests is more than welcome.

The question is more: should you put it on the roadmap of OPAM (so
that Louis can work on it after the release at some point), or do you
prefer to wait for somebody to contribute it from the outside of the
OPAM project ?

--Fabrice