Am Sonntag, den 11.12.2011, 00:28 +0100 schrieb Jesper Louis Andersen:
> On Sat, Dec 10, 2011 at 15:45, Xavier Leroy <xavier.le...@inria.fr> wrote:
>
> > 2- As pointed out already in this discussion, it's not on the Caml compiler
> > that community efforts are most needed. For example, the most impactful
> > action that his community could take, in my opinion, is to adopt and embrace
> > a common packaging system like Cabal for Haskell.
>
> This one piqued my interest somewhat. I should refrain from
> commenting, but I can't help myself.
It's interesting to hear these comments. In short, in ocaml we have
these options:
- Full featured package management: we have this (GODI), but the
community is not too large (package maintainers are always
welcome!) As every full-featured system, GODI has complicated
parts, and you need to invest 1-2 days before you fully
understand it and can build packages.
- Simplified package management: This is what OASIS-DB tries to do.
Fewer features, but it is easier to create new packages. Hopefully,
it will attract more developers. OASIS-DB can be integrated into
full-featured systems like GODI or Debian, so the idea is also
to avoid duplicate work.
- Bottom end: Findlib and the build tools (ocamlbuild and omake).
This already includes dependency management on the "compiler
switch level"
This means, the situation is not too bad. OASIS-DB is the missing link
between the build tools and the high-level packaging systems.
> What makes the Cabal infrastructure successful is that it is three
> different types of systems in one. First, there is hackage which
> provides a package repository of "blessed" packages - online search of
> the repository and general dumping ground of rotting packages. In
> other words, a perl CPAN for Haskell. Quality varies a lot, but at
> least there is a go-to place when searching for packages.
For GODI we have docs.camlcity.org. Once there is OASIS-DB, these
packages will also be covered (automatically).
> Second, Cabal provides a system for automatically building packages.
> That is, if you have cabal, chances are that you can just blindly ask
> it to build the source code and you are done.... when it works.
>
> Thirdly, Cabal provides dependency tracking among packages. That is,
> given a package, you can easily fetch its dependencies and build
> another version of the package yourself.
>
> That said, my personal opinion, which probably not means much as I
> don't currently write scores of Ocaml or Haskell source, is still that
> Cabal is somewhat overengineered. Usually you end up with trouble when
> you try to build new packages. If you forget profiling flags, you have
> to rebuild essentially everything.
Sounds more like it is underengineered - or leaves too many options for
the users to create errors.
However, there is certainly always a complexity problem in full-featured
package managers. We see this problem in GODI, too, and this is probably
why it is hard to convince people to help creating packages. Once a
package exists, GODI is very simple to use, but getting there is not
completely easy.
> Multiple versions of packages
> creates headaches when trying to use them
Well, I do not know any package manager that supports this feature well.
Finally, you have to decide to use a certain version.
> (think the diamond-problem
> in a subtyping setting with multiple inheritance or functors without
> sharing constraints). And when I build Haskell source, I usually end
> up cursing the hell out of Cabal :)
>
> Erlang has a tool, doing parts two and three above: rebar. This tool
> is fundamentally simpler than Cabal. Its dependency tracking is
> essentially download instructions from software repositories and
> that's it. Packaging is done by creating the equivalent of static
> binaries .. dependencies are shoved into a release of an erlang
> runtime with all the necessary modules ready into a selfhosting,
> selfcontaining system. The approach is *much* simpler, but it works
> tremendously well.
Sounds like this is more on the level of OASIS-DB.
> Even if it doesn't handle the problem of the
> diamond. It also allows different software to use different versions
> of libraries, but it doesn't really solve dependency convergence (that
> is yet another name for the diamond problem: A needs B and A needs C -
> but B needs D in version 1 and C needs D in version 2):
>
> digraph {
> D -> B -> A;
> D -> C -> A
> }
Right, this is what makes it difficult to support several versions in
the same repo.
> In my experience, it is the simple solutions that works best, even if
> they can't handle certain scenarios. In some sense a certain amount of
> limitation is more a virtue than a curse. I'd also suggest splitting
> the search and indexing part from the dependency tracking and building
> part. They are far enough apart that they can be solved each by
> themselves.
Well, this is not completely independent (I can say this as developer of
docs.camlcity.org). Indexing profits a lot from having a compiled
version of the packages, because you have a strict name lookup then
(i.e. when a name comes from a predecessor package, you can resolve this
dependency easily, and you do not have to resort to fuzzy methods of
lookup).
Also, in docs.camlcity.org we can present the user the resulting file
tree after a package is installed. This is at least interesting
information.
> Finally there are two other things I would recommend one investigates:
> FreeBSD ports or Mac OSX homebrew for the indexing part. And pythons
> virtualenv (Ian Bicking was the original author). Virtualenv allows
> you to build a "virtual environment" in which you install python
> packages, which are distinct from the system installation. Of course
> you can symlink system libraries into the virtual environment, but it
> also means that programs can live next to each other and the
> sandboxing going on solves a lot of dependency problems in a simple
> way.
>
> In other words, to solve this, I'd much rather try to rig the
> excellent Ocamlbuild and Ocamlfind infrastructure such that it
> incorporates some of the above things, ... that is if it doesn't do
> that already...
Well, we are a bit farther than you knew, obviously :-)
Gerd
> --
> J.
>
>
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
