caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Edgar Friendly <thelema314@gmail.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] odb questions
Date: Wed, 07 Mar 2012 09:37:06 -0500	[thread overview]
Message-ID: <4F577292.1070502@gmail.com> (raw)
In-Reply-To: <35CD2569B25340E28784ABDB2505BDC2@erratique.ch>

On 03/07/2012 07:32 AM, Daniel Bünzli wrote:
> Hello,
>
> A few questions about odb.
>
> 1) Is it possible to specify in ~/.odb/packages a remote packages file (instead of just individual remote packages) ?

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.
>
> 2) How does odb find out and manage dependencies ? How can I list them before installing a package ?
>
Odb uses findlib to determine what libraries are installed.  For 
executables, the unix command `which` is used.  In the works is 
extracting the version of executables from running the command with 
`-version`.

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.

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?

> 3) Are multiple versions of the same package supported (à la homebrew on osx) ?
>
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.

> 4) Is something like odb install -file package.tbz possible ?
>
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

> The use case for 4) is both for testing and so that I can instruct my users once they have downloaded a tbz and went through the README that they can just install it with that command (provided they have installed other deps).
>
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.  Then once you've got it 
working, make a simple _oasis file for it, and upload it to oasis-db - 
then everyone will gain access to it automatically.

> Daniel
>
> P.S. I think odb should use a odb<cmd>  scheme. Instead of just installing on odb<pkg>. The former scheme has better scaling opportunities.

Except I don't intend odb to scale.  It's hovering right around 500 
lines of code, and if I can keep it around that size, I'll be happy.  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.

E.

  reply	other threads:[~2012-03-07 14:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 12:32 Daniel Bünzli
2012-03-07 14:37 ` Edgar Friendly [this message]
2012-03-07 15:47   ` Daniel Bünzli
2012-03-07 15:58     ` Edgar Friendly
2012-03-07 16:28       ` Daniel Bünzli
2012-03-09 14:26       ` Daniel Bünzli
2012-03-09 16:26         ` Edgar Friendly
2012-03-09 16:47           ` Daniel Bünzli
2012-03-08  1:02   ` Francois Berenger
2012-03-08 13:29     ` Edgar Friendly
2012-03-08 15:41       ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F577292.1070502@gmail.com \
    --to=thelema314@gmail.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).