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