Re: AW: [Caml-list] GODI is shutting down

[Thomas Gazagnaire <thomas@ocamlpro.com>]

> In the past days I made the experience that OPAM advocates never answer to any of my objections. When I said "GODI has feature xy, why doesn't OPAM has this too?" the only response is something like "OPAM has this great Github-based workflow" (the most harmless variant). Discussion impossible.

Let's try to be constructive then. I've tried to look for all your recent objections, let me known if I have missed some.

1. " Instead, there was later questionable behavior from Ocamlpro, namely that they copied (at least parts of) GODI packages, without having asked for permission. (In particular, there was evidence that they copied the package description texts.) This might be legal, but the reader will understand that this is unfriendly, and unneccessarily aggressive. At that point it was clear that they are trying to push GODI aside, even with questionable means."

Some of the initial package descriptions were indeed copied from the description files of the corresponding GODI packages (which have been often itself copied from the author website). I was not aware of this when the descriptions got integrated in the repository, and I've removed them as soon as the issue has been raised on the GODI mailing list [1, 8 oct 2012] and [2, 8 oct 2012]. To avoid such issue in the future we are planning to clarify the licensing scheme on all the metadata published on the "official repository" (we would like to make it public domain if possible, but it's maybe too late).

[1] https://godirepo.camlcity.org/pipermail/godi-list/2012-October/003517.html
[2] https://godirepo.camlcity.org/pipermail/godi-list/2012-October/003521.html

2. "It doesn't matter that OPAM lacks core functions like deleting all files when a package is removed"

I was very surprised when I've read that (and I though it was just an unrelated rant), but as you seem to insist I guess you are serious. Where did you read that ? Of course, OPAM deletes the files it has installed!

- It removes $prefix/lib/<name>, $prefix/doc/<name> (and the other usual paths associated to a package, but keeps $share/<name> for future reinstallations) and it calls whatever removal scripts the user has registered (which is 'ocamlfind remove <name>' for most of the packaged libaries -- which is still useful when you have C stubs to remove in $prefix/stublibs), and;

- It also removes the files specified in an optional `<name>.install` file located at the root of the directory (which is useful when you have binaries). We have some experimental features to scan the filesystem before and after the installation, and update the corresponding `<name>.install` file with the difference but it's quite slow (because of the filesystem scanning) and this does not work when the number of jobs is greater than 1. But I would prefer to let that task to the packagers (or to their build-system, see for instance that nice omake extension[3])

[3] https://github.com/smondet/dircmp/blob/master/OMakeroot#L175

3. "There is the QA question, at least for the main repository"

This is on-going work. The first objective was to gather as much packages as possible, and to make people start to rely on other people packages instead of restarting each projects from scratch. Now we are starting to focus on the QA side, as Anil already have already told you in a previous email, as we slowly replace our old private Jenkins setup by a more advanced, fully written in OCaml -- but still experimental -- testing platform. Look at the the 4.00.1 on linux results they are the more meaningful for now on, more than 90% of the packages are working fine (and yes, that's definitely needs to be improved, but I would say that's not so bad).

https://ocaml-www3.ocamllabs.cl.cam.ac.uk/github/OCamlPro/opam-repository

Then, as discussed on [4], we plan to select the package with the right level of QA to be part of the upcoming "OCaml Platform". The platform itself will either be a separate repository, or a separate branch or simply a virtual package in the main repository -- as explained in [4] (and on other threads of the platform list) the contents of the platform will be driven by QA criteria.

[4] http://lists.ocaml.org/pipermail/platform/2013-February/000001.html

4. "how well a library is integrated into the OS"

Currently, with a minimal support. We are working on improving that. Look at the `depext` field in the sqlite3-ocaml package[5], that you can query using the command-line:

$ opam install sqlite3-ocaml -e debian,wheezy,amd64
libsqlite3-dev

The goal is to use that metadata to "drive" the installation/checks of external dependencies, depending on the user host and OS. The short-term goal is to display nice error messages though.

[5] https://github.com/OCamlPro/opam-repository/blob/master/packages/sqlite3-ocaml.2.0.4/opam

5. "lack of windows support and binary packages"

OPAM supports for Windows is not so good at the moment indeed. However, things are getting better as we are improving the support for windows (we have a private version which compiles and run OK on cygwin for basic packages) and we have an experimental binary support that we are still prototyping [6]. GODI and WODI are clearly in advance in this domain (but I recall that WODI is a relatively new project).

[6]. https://github.com/venator/opam/tree/binary

6. "No, all package managers should unite in this point, and only accept
packages with oasis support. (Btw, that's homework for me.) Just do it the
same way as we did when requiring findlib."

I disagree, people should be free to use whatever system they want.

7. About the generation of OPAM files from _oasis

I am not totally convinced by all the arguments I seen so far. Making a new release because a package constraint is wrong seems not to be a good idea to me. A large proportion of pull request in the the package metadata's repository is about fixing such dependency constraints (which are discovered by our testing tools). I don't have a yet a good story to bring that information back into the package, but I'd say that I'm not very fond of mixing everything together: let's keep the dependency constraints part of the package system and the build instruction part of the build system -- that's much simpler that way.

8. "You are a victim of OPAM's campaign."

Sorry, I have no facts to answer here.


Best,
Thomas