Re: [Caml-list] Alternative proposal: COAN

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

The idea to simplify package management in ocaml is certainly a good
one. I personally agree very much with Roberto, at least on the issues.

From: roberto@dicosmo.org
> But it is probably necessary here to clearly separate the different issues...
> at first sight, I see:
> 
> - centralized repository:
>     Issue: we want some central place where to look for Ocaml code
>            without resorting to google
> - easy installation:
>     Issue: I want to run advi to give flashy LaTeX presentation, and I want t
>            just get a binary for my nice OS I love so much, without having to
>            recompile anything
> - dependency tracking:
>     Issue: we would really really like to avoid reading "README"s
>            to discover the zillion packages on which the next future
>            generation Ocaml killer application will depend. Just
>            type "install XYZ" and that's it. 

His conclusion was that apt-get (or something similar) is the way to
go. I agree mostly with this too, but my experience with BSD ports and
ocaml upgrading nightmares makes me differ on details.

* For me the central repository should not contain the source themselves.
  This was an error with the CDK: the distribution becomes huge, and
  it is very difficult for the maintainers to track changes 
  by developpers (who do not necessarily want to work in that
  repository, for evident practical reasons). Not speaking of
  licensing problems.
  With BSD ports, the central repository only contains metadata, that
  it a directory for each package, with its name, its dependencies,
  where to find it, how to configure and install it, and eventually
  some patches to make it fit in the system.
  The central repository would be a small one containing only
  metadata, updated often, eventually by authors themselves. Users who
  want newest stuff update by cvs, others get snapshots. Ideally some
  snapshots go through testing to become releases.
  The sources themselves are distributed as tarballs. This may be a
  good idea to replicate them on a few ftp servers, but there is no
  reason to make it compulsory.
  
* Easy installation means that you should be able to download, compile
  and install the desired ocaml program or library in one single
  command, including all the dependencies.
  This does not mean that a binary should be available. A binary will
  only work with a single version of ocaml and all dependencies, which
  is way too restrictive. Binaries may be provided on a by OS basis,
  but then it is much more comfortable for users to use the packaging
  system provided by the OS (tgz on FreeBSD, rpms on redhat, deb on
  debian, pkg on OSX, ??? on windows...) If the basic framework is
  right, that work should be easy enough.

* Dependency resolution and automatic recompilation/reinstallation is
  the core of the problem.
  When you modify an ocaml library, all its dependencies have to be
  recompiled. You certainly want to automate this, and have some
  foolproof system to be able to go back to a stable state. This is
  also an area where a bit of compiler "support" may become necessary.
  At least, have different library directories for different version
  of ocaml, ideally some scheme a la OSX to install several versions
  of the same package in parallel.

I personally don't think that standardizing the tools to produce
individual package is a useful move. Providing good tools to ease
package construction matters, but enforcing them on developpers is
counter-productive.  What is needed is just the glue to make it
uniform from the user point of view. Ocamlfind can probably
help there for complex cases, but as simple cases work well enough
with ocamlc, I would prefer it to stay optional for end-users (this is
certainly OK to rely on it in the implementation of the system).

One last comment on Windows. Since most development is taking place on
Unix, I think this is reasonnable to make the presence of basic cygwin
tools a requirement for compiling packages. The presence of gnu make
and some shell commands should be enough for most. Handling of C
libraries is more complex, but this must often be handled also at the
source level.

Thanks for reading my personal opinions.

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners