[Caml-list] Package installation assumptions made by odb

[Caml-list] Package installation assumptions made by odb

[Edgar Friendly]

odb is a simple ocaml program to install ocaml packages with 
dependencies.  I've written a document on the assumptions it makes of 
the packages it's to install.  By sharing this, I hope to influence 
library and application developers to use a standard interface for 
compiling their program.

The details are here: 
https://github.com/thelema/odb/blob/master/guidelines.md

Thank you for any feedback.  Please bear in mind that odb is meant to be 
simple, so the complexity of configuring, building and installing any 
packages is expected to be in that package's build system, and not odb 
itself.

E.

Re: [Caml-list] Package installation assumptions made by odb

[Arnaud Spiwack]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

I see an immediate problem with packages that install several executable
files (for instance, Melt provides a library and a collection of tools,
none of them named melt, by the way). I haven't spent time looking more
than superficially into oasis or odb yet, but it strikes me as a possibly
important limitation.

--
Arnaud Spiwack

On 11 February 2012 22:10, Edgar Friendly <thelema314@gmail.com> wrote:

> odb is a simple ocaml program to install ocaml packages with dependencies.
>  I've written a document on the assumptions it makes of the packages it's
> to install.  By sharing this, I hope to influence library and application
> developers to use a standard interface for compiling their program.
>
> The details are here: https://github.com/thelema/**
> odb/blob/master/guidelines.md<https://github.com/thelema/odb/blob/master/guidelines.md>
>
> Thank you for any feedback.  Please bear in mind that odb is meant to be
> simple, so the complexity of configuring, building and installing any
> packages is expected to be in that package's build system, and not odb
> itself.
>
> E.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/**wws/info/caml-list<https://sympa-roc.inria.fr/wws/info/caml-list>
> Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-**bugs<http://caml.inria.fr/bin/caml-bugs>
>
>

[-- Attachment #2: Type: text/html, Size: 1969 bytes --]

Re: [Caml-list] Package installation assumptions made by odb

[Edgar Friendly]

On 02/13/2012 06:01 AM, Arnaud Spiwack wrote:
> I see an immediate problem with packages that install several executable
> files (for instance, Melt provides a library and a collection of tools,
> none of them named melt, by the way). I haven't spent time looking more
> than superficially into oasis or odb yet, but it strikes me as a
> possibly important limitation.
>

It looks like the executable is now named melt-build.  In this case, odb 
would expect the melt project name to be "melt-build" so that its simple 
logic can detect if melt is already installed.  This does not have any 
affect beyond changing the name that must be typed on the command line 
to install melt (`odb melt-build` instead of `odb melt`), and the name 
for dependencies by other projects (projects depending on melt would 
have to specify `dep=melt-build` instead of `dep=melt`).

Also, if melt installs an ocamlfind library named melt, then its odb 
package name could be melt or melt-build, depending on which part of 
melt should be used to detect its installation.  At the moment, odb 
doesn't really do version handling (mainly because it's difficult to get 
a version number from an executable), although this is a weakness where 
odb might improve.

This assumption of executables and libraries being named the same as the 
package isn't critical to the design of odb, it's just a simplifying 
assumption that works quite well (and would work for melt up to the last 
version when its executable was renamed).  If there's good reason to 
have more complex installed-program detection, this is easily doable, 
but the workarounds are simple enough at the moment that this doesn't 
seem to be a problem.

E.

Re: [Caml-list] Package installation assumptions made by odb

[Romain Bardou]

Le 13/02/2012 14:04, Edgar Friendly a écrit :
> On 02/13/2012 06:01 AM, Arnaud Spiwack wrote:
>> I see an immediate problem with packages that install several executable
>> files (for instance, Melt provides a library and a collection of tools,
>> none of them named melt, by the way). I haven't spent time looking more
>> than superficially into oasis or odb yet, but it strikes me as a
>> possibly important limitation.
>>
>
> It looks like the executable is now named melt-build. In this case, odb
> would expect the melt project name to be "melt-build" so that its simple
> logic can detect if melt is already installed. This does not have any
> affect beyond changing the name that must be typed on the command line
> to install melt (`odb melt-build` instead of `odb melt`), and the name
> for dependencies by other projects (projects depending on melt would
> have to specify `dep=melt-build` instead of `dep=melt`).
>
> Also, if melt installs an ocamlfind library named melt, then its odb
> package name could be melt or melt-build, depending on which part of
> melt should be used to detect its installation. At the moment, odb
> doesn't really do version handling (mainly because it's difficult to get
> a version number from an executable), although this is a weakness where
> odb might improve.
>
> This assumption of executables and libraries being named the same as the
> package isn't critical to the design of odb, it's just a simplifying
> assumption that works quite well (and would work for melt up to the last
> version when its executable was renamed). If there's good reason to have
> more complex installed-program detection, this is easily doable, but the
> workarounds are simple enough at the moment that this doesn't seem to be
> a problem.
>
> E.
>

Hello,

I agree with Arnaud: although this behavior is simple to implement and 
understand (which is good) I see several cases where it would be a 
problem. For instance, I'm currently working on a suite of tools named 
like foo-feature1, foo-feature2, foo-feature3 and so on. The package 
would obviously be named foo, but it does not make sense to have a 
single "foo" executable. It does not make sense to have once package per 
executable either. So I guess you need some way to override this 
behavior when needed. Can odb extract this kind of information from an 
_oasis file, or from a META file? I'm not very familiar with those.

Regarding Melt, I'm a bit confused: you say in this mail that "its odb
package name could be melt or melt-build, depending on which part of
melt should be used to detect its installation". But in your guidelines 
it is written: "Programs that are both should do both". By the way, Melt 
actually installs two libraries: Melt and Latex.

Regarding the version number, if you need to define a standard I think 
it would be good if this standard was to call the executable with the 
"-version" option. It is, after all, the behavior of "ocamlc". This does 
not work for libraries though; here there are several possibilities:
- compute a hash of the .cma / .cmxa, but you need a database of 
hashtables -> version;
- dynamically link with the .cma / .cmxa, assuming a module "Version" 
with a variable containing the version (but this is not very practical 
for many reasons).

My 2 cents,

-- 
Romain Bardou

Re: [Caml-list] Package installation assumptions made by odb

[Török Edwin]

On 02/13/2012 03:39 PM, Romain Bardou wrote:
> Le 13/02/2012 14:04, Edgar Friendly a écrit :
>> On 02/13/2012 06:01 AM, Arnaud Spiwack wrote:
>>> I see an immediate problem with packages that install several executable
>>> files (for instance, Melt provides a library and a collection of tools,
>>> none of them named melt, by the way). I haven't spent time looking more
>>> than superficially into oasis or odb yet, but it strikes me as a
>>> possibly important limitation.
>>>
>>
>> It looks like the executable is now named melt-build. In this case, odb
>> would expect the melt project name to be "melt-build" so that its simple
>> logic can detect if melt is already installed. This does not have any
>> affect beyond changing the name that must be typed on the command line
>> to install melt (`odb melt-build` instead of `odb melt`), and the name
>> for dependencies by other projects (projects depending on melt would
>> have to specify `dep=melt-build` instead of `dep=melt`).
>>
>> Also, if melt installs an ocamlfind library named melt, then its odb
>> package name could be melt or melt-build, depending on which part of
>> melt should be used to detect its installation. At the moment, odb
>> doesn't really do version handling (mainly because it's difficult to get
>> a version number from an executable), although this is a weakness where
>> odb might improve.
>>
>> This assumption of executables and libraries being named the same as the
>> package isn't critical to the design of odb, it's just a simplifying
>> assumption that works quite well (and would work for melt up to the last
>> version when its executable was renamed). If there's good reason to have
>> more complex installed-program detection, this is easily doable, but the
>> workarounds are simple enough at the moment that this doesn't seem to be
>> a problem.
>>
>> E.
>>
> 
> Hello,
> 
> I agree with Arnaud: although this behavior is simple to implement and understand (which is good) I see several cases where it would be a problem. For instance, I'm currently working on a suite of
> tools named like foo-feature1, foo-feature2, foo-feature3 and so on. The package would obviously be named foo, but it does not make sense to have a single "foo" executable. It does not make sense to
> have once package per executable either. So I guess you need some way to override this behavior when needed. Can odb extract this kind of information from an _oasis file, or from a META file? I'm not
> very familiar with those.
> 
> Regarding Melt, I'm a bit confused: you say in this mail that "its odb
> package name could be melt or melt-build, depending on which part of
> melt should be used to detect its installation". But in your guidelines it is written: "Programs that are both should do both". By the way, Melt actually installs two libraries: Melt and Latex.
> 
> Regarding the version number, if you need to define a standard I think it would be good if this standard was to call the executable with the "-version" option. It is, after all, the behavior of
> "ocamlc". This does not work for libraries though; here there are several possibilities:
> - compute a hash of the .cma / .cmxa, but you need a database of hashtables -> version;
> - dynamically link with the .cma / .cmxa, assuming a module "Version" with a variable containing the version (but this is not very practical for many reasons).

- Use the 'version' from the library's META file (if any):
$ ocamlfind query -format '%v' sexplib
7.0.4


Best regards,
--Edwin

Re: [Caml-list] Package installation assumptions made by odb

[Edgar Friendly]

On 02/13/2012 08:39 AM, Romain Bardou wrote:
> For instance, I'm currently working on a suite of tools named
> like foo-feature1, foo-feature2, foo-feature3 and so on. The package
> would obviously be named foo, but it does not make sense to have a
> single "foo" executable. It does not make sense to have once package per
> executable either.

If it's all compiled at once, it's probably one package - don't split it 
up.  I see three options:
1) name your package (in odb) foo-feature1 (ugly, but simple and works)
2) provide a dummy executable `foo` for odb to detect
3) convince me that your requirements are common enough to deserve more 
complexity in odb

There's no need for odb to detect (or even know about) all three 
foo-features, it's perfectly fine for it to only know about one of them 
and base its decision to recompile on that one.

> So I guess you need some way to override this
> behavior when needed. Can odb extract this kind of information from an
> _oasis file, or from a META file? I'm not very familiar with those.
>
odb doesn't directly access either of those files.  Oasis-db extracts 
lots of info from _oasis files and make them available to odb in a form 
it understands.  Findlib also handles META files on behalf of odb, 
although for different uses.

> Regarding Melt, I'm a bit confused: you say in this mail that "its odb
> package name could be melt or melt-build, depending on which part of
> melt should be used to detect its installation". But in your guidelines
> it is written: "Programs that are both should do both". By the way, Melt
> actually installs two libraries: Melt and Latex.
>
At the moment, the library/executable distinction is important only for 
detecting installed packages.  If a package is a library, it is 
installed only if ocamlfind knows of an ocamlfind package with the same 
name as the odb package.  Similarly, if a package is a executable, it is 
installed only if `which` knows of that executable name.

> Regarding the version number, if you need to define a standard I think
> it would be good if this standard was to call the executable with the
> "-version" option. It is, after all, the behavior of "ocamlc". This does
> not work for libraries though;

Libraries are not a problem - ocamlfind provides a version for them 
trivially (from their META file).  IIRC, I wrote some code that tried to 
run `foo -version` to get the version of foo, but it looks like I'll 
have to parse the output of most programs looking for a version number.

E.