Re: [Caml-list] [OSR] Ports-like package management system

["Bünzli Daniel" <daniel.buenzli@erratique.ch>]

Le 29 janv. 08 à 11:56, Berke Durak a écrit :

> We thus need versions, and lots of them!  We need to base our
> developer packages on a version control system, in the style of BSD
> ports.  BSD ports are usually based on CVS, sometimes on Subversion.

My experience with bsd-like port systems (at least darwinports) is  
that _port description files_ are versioned. But the bits they compile  
are tarball releases, they do not pull directly out of the projects'  
vcs to install your local copy.

I would be all in favor of using somehting like darcs2 because it is  
what I use. However I don't think it is a good idea to impose a vcs to  
developers, they should be free to use their own. I don't understand  
why you don't want to rely on tarballs, one per version, with a  
facility to quickly create and upload them.

> As we are looking to increase collaboration, having a single point of
> contention is a serious limitations of these centralized systems;
> we'll prefer more recent "distributed" version control system.

You are right everyone should be able to publish its package on its  
own server and mirrors (it also solves the problem of who is going to  
pay for the infrastructure). But this has nothing to do with  
distributed vcs.

> Assume you are writing a program FOO and want to use a package BAR
> available from bar.org.  You tell ocamlbuild by adding some tag such
> as
>
>  <mytarget.native>: require(http://bar.org/repository/)

This is good, FOO's dependencies are explicit. However I'm not sure a  
direct uri is a good thing, you'll need something to be able to  
specify alternate download sites. The package name + version  
specification should be decoupled from the uri you use to access it.  
Even if you do that nothing prevents you to implement this over plain  
http. E.g. you have download locations uri1 uri2, and a package-name  
and version-name then you try to download from uri1/package-name/ 
version-name and then if it fails uri2/... Of course in that case  
you'll need digests.

> Of course it should be possible to specify a particular revision...

For me this is too fine grained -- and this is also the reason why you  
want to integrate a vcs to your system. I would like to be able to  
specify a version that the developer of the package deemed stable  
enough to distribute, not a random revision. I strongly think that  
tarball releases are enough, if there are simple and efficient tools  
to produce them. Going down to the revision is overkill.

>   I know there is Omake,

Having used ocamlbuild for caml projects, for me it is out of question  
to return to something make-like.


Le 29 janv. 08 à 14:11, Yaron Minsky a écrit :

> It would also be nice to have a set of versions of the various  
> libraries that hang together, as GODI does.  Otherwise, problems in  
> the case where there are packages A, B and C where A depends on B  
> and C and B depends on C.  You need a version of C that works with  
> your versions of A and B, or you're sunk.  So some central repo  
> where you can maintain a set of "safe" versions would allow for a  
> developer to ask for a easily pull a collection of working libraries.

These are the kind problem you get when you go distributed. For  
emergencies you need at least an override mechanism (use this version  
instead of that one to build all packages). The rest should be solved  
by cooperation between developers. But nothing prevents someone to  
construct a cathedral, godi-like, collection of packages well tested  
to work toghether and that you will use as your only source. It is  
easy to build a centralized system on a distributed one, but the  
converse is not true.

At the risk of repeating myself I'll point again to my partial mod  
proposal [1], some of the ideas there could be recast more thightly  
with ocamlbuild as is  propose above. This would certainly also  
simplify the proposal (which was supposed to be a tool really  
separated from ocamlbuild).

Best,

Daniel

[1] http://erratique.ch/writings/mod.pdf