[opam-devel] ows reports
thomas at gazagnaire.org
Thu Oct 2 11:53:49 BST 2014
> ─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.
You are conflating "a package is unavailable because he has an available filter" and "a package is unavailable because one of its hard dependency is unavailable". `opam list --all` discards both kinds of packages but ows distinguish them. You are also conflating "at least a version of a package is installable" (which is what `opam list --all` shows) and all versions of the package are available (which is what is showed in ows).
So again, it's unclear to me what exactly is the metrics ows is supposed to reflect, for an user point-of-view and for a maintainer point-of-view. Maybe a good start should be to explain what you are trying to measure and how this is related to the quality an user will perceive.
> 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).
not sure we are checking that the results of a search are installable. worth filling an issue on github about that.
> 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).
js-lz4 is not installable so it does not show in the results of `opam list --all`.
>> 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 ?
yes, but that's not a problem as long as it reflects reality and there is a way to improve
> 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.
Anil and I are "responsible" for fixing the policies to accept or not packages. We try to advise people on how to improve. For instance, it is not clear to me what to say to jane-street to improve the quality of their packages in ows. They follow they workflow we have defined initially.
>> 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.
opam removes the transitive closure of unavailable packages in `opam list --all`. But yes, maybe we need more meta-data. Is that the solution you recommend?
More information about the opam-devel