Re: [Caml-list] The DLL-hell of O'Caml

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Mark D. Anderson wrote:
> If someone is going to work on this, I'd recommend they look even more deeply
> at what perl and python do. It is more than just "download over http"; there
> are also issues of versioning among others.

But there is a fundamental difference: These language don't have strict
typing, and they bind identifiers always dynamically. It is no problem
to replace a version of a library by a newer one. Of course, this can
also break functionality, but it is possible to develop module
interfaces conservatively.

In O'Caml replacing library X by a newer version usually means that
all libraries Y that depend on X must be recompiled. And there is no
guarantee that Y can be compiled at all. I do not see any chance to
change this, it is a consequence of strict typing.

So an automatic installer for O'Caml needs:

- A local source repository that stores all sources so modules can
   be recompiled if necessary

- Knowledge about the versions of modules, especially which versions
   of dependent modules work together and which don't

> Some of the things both those languages have, to greater or lesser degrees:
> 
> - there is a web site for humans with search and list, such as search.cpan.org

We have already two, but they are for humans only.

> - there is a command line which does search, list, and install, such as 
> "perl -MCPAN -e shell" or "ppm"
> (ppm is more an activestate thing; CPAN.pm is distributed)
> The install can deal with recursive dependencies if you want.

If it is only search/list/install package management is quite easy.
We need a file format that contains the instructions how to build
a package from source.

But upgrades are more complicated, as explained.

> - the install utility can handle pure language packages, mixed language packages
> with C source, and mixed language packages with pre-compiled C source
> for one architecture (ppm is less flexible but simpler).
> 
> - really obscene things can be done with the perl "Inline" module: http://search.cpan.org/search?dist=Inline
> 
> - a single language install tree can handle a mixture of binary modules that vary by
> architecture (i686-linux vs. MSWin32-x86-multi-thread) or by language version (5.005 vs. 5.6).
> pure-language modules can vary by language version.
> This is useful for multiple developers sharing a single install over NFS, or for
> a single developer that is trying out multiple configurations.

Again, this works only because the modules are loosely coupled.

> - the language runtime does best effort when a package is asked for by name,
> taking the "best-fit" one;
> this prevents you having to upgrade all packages just because the language is
> upgraded.

Maybe we are on the wrong track if we want to mimick Perl's installer.
Maybe it is better not to have a fully automatic system but a system
that is more user-friendly. I can imagine a graphic tool would be
helpful that visualizes the current state of the installation, that
explains possible operations, and that assists the user when carrying
them out.

For example, if a package is upgraded, this tool would not try to
recompile the dependent packages automatically, but it would display
that these packages are currently invalid and need to be replaced.
The user would have the chance to control the next steps. One
possibility would be to try to recompile the old version again,
another would be to get a new version from a remote repository.
The point is that it is under the control of the user, and that
the graphic visualization allows even beginners to manage
upgrades.

Gerd

-------------------
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