From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q27FlTlw004724 for ; Wed, 7 Mar 2012 16:47:29 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEDANuCV09KN1ZKlWdsb2JhbABChUGwBQEBAQEJCwkJEimCCgEBBAEjVgULCw4MAhgOAgI9ChAGGxOHaAUErQWKWoEvjiozYwSbEo0q X-IronPort-AV: E=Sophos;i="4.73,545,1325458800"; d="scan'208";a="148068174" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail1-smtp-roc.national.inria.fr with ESMTP; 07 Mar 2012 16:47:10 +0100 Received: from heyho.local (13-234.197-178.cust.bluewin.ch [178.197.234.13]) by smtp.webfaction.com (Postfix) with ESMTP id 1D26F59D060C; Wed, 7 Mar 2012 09:47:07 -0600 (CST) Date: Wed, 7 Mar 2012 16:47:04 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Edgar Friendly Cc: caml-list@inria.fr Message-ID: <5DE1EE40F73548B89972BC0971BA23BA@erratique.ch> In-Reply-To: <4F577292.1070502@gmail.com> References: <35CD2569B25340E28784ABDB2505BDC2@erratique.ch> <4F577292.1070502@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q27FlTlw004724 Subject: Re: [Caml-list] odb questions Le mercredi, 7 mars 2012 à 15:37, Edgar Friendly a écrit : > Not at the moment, but this is an interesting idea. The only support > for remote packages is the querying of oasis-db. The protocol is nearly > trivial, so you're welcome to make your own server (can be just a plain > web server serving static text files) and set the odb repository URL to it. Okay. Would be nice to have the support in the tool and documentation on how to make your own package source (basically GET on a ~/.odb/packages file ?). Package distribution should be distributed. > The other end of this is handled by odb's metadata that specifies things > like where to get the source code, dependencies, installation > requirements, and other useful information for installing. There are > two sources for this metadata: 1) oasis-db by http 2) packages files > locally. The packages files are parsed on startup, if odb needs info > about a package not in this cache, it queries oasis-db for the metadata. By 2) you mean what is described in "Local packages" here : https://github.com/thelema/odb ? Because the syntax for specifiying deps is not documented. > I like the idea of printing deps without installing, and it should be > pretty easy to implement. It'd probably suffice to just print the whole > metadata; it's quite readable. Maybe metadata + dependency check will > satisfy your needs? Why not ? > This is supported in two ways. First through environment variables that > basically switch between different ocaml installations / ocamlfind root > paths. Odb relies on findlib to manage libraries, and it supports this > through tweaking install paths. > > The other way is to have packages batteries1 and batteres2 that both > install different versions of batteries, and as long as they register in > findlib with the names batteries1 and batteries2, odb will treat them as > different. IMHO a package should be identified by a name and version. > It's planned to be able to give a full package info on the command line, > so this would be more like: > > odb tarball=package.tbz deps=odn,batteries That would be nice. > The current way to do testing is to put a line in your local packages > file (two locations that are scanned for one: ~/.odb and the odb script > dir), and use the info there for testing. Okay but how do I specify deps ? I'm sure I can quickly find out but I want you to update the docs... > Except I don't intend odb to scale. Pity. > It's hovering right around 500 > lines of code, and if I can keep it around that size, I'll be happy. That's indeed a good thing, aswell as no deep deps. But hey, setup.ml is around 10x more (which makes it unusable for dev. btw.) you still have some way to go. > I > don't intend odb to ever have a `odb remove foo` command, nor an `odb > update`. Maybe I'll have an `odb upgrade`, but I'm happy leaving this > as `odb --upgrade`. Odb's goal is to be an 80% solution, and it was > that a while ago, I think. It's approaching 90%, and I'm going to try > to avoid it feature creeping to 100%. Oddities should be handled by the > package installers themselves or the metadata repository as much as > possible, leaving pretty little work for odb. Pity. I like odb's down to earth approach. Best, Daniel