* [Caml-list] Package installation assumptions made by odb @ 2012-02-11 21:10 Edgar Friendly 2012-02-13 11:01 ` Arnaud Spiwack 0 siblings, 1 reply; 6+ messages in thread From: Edgar Friendly @ 2012-02-11 21:10 UTC (permalink / raw) To: caml-list 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Package installation assumptions made by odb 2012-02-11 21:10 [Caml-list] Package installation assumptions made by odb Edgar Friendly @ 2012-02-13 11:01 ` Arnaud Spiwack 2012-02-13 13:04 ` Edgar Friendly 0 siblings, 1 reply; 6+ messages in thread From: Arnaud Spiwack @ 2012-02-13 11:01 UTC (permalink / raw) To: Edgar Friendly; +Cc: caml-list [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Package installation assumptions made by odb 2012-02-13 11:01 ` Arnaud Spiwack @ 2012-02-13 13:04 ` Edgar Friendly 2012-02-13 13:39 ` Romain Bardou 0 siblings, 1 reply; 6+ messages in thread From: Edgar Friendly @ 2012-02-13 13:04 UTC (permalink / raw) To: Arnaud Spiwack; +Cc: caml-list 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Package installation assumptions made by odb 2012-02-13 13:04 ` Edgar Friendly @ 2012-02-13 13:39 ` Romain Bardou 2012-02-13 13:46 ` Török Edwin 2012-02-13 13:53 ` Edgar Friendly 0 siblings, 2 replies; 6+ messages in thread From: Romain Bardou @ 2012-02-13 13:39 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Package installation assumptions made by odb 2012-02-13 13:39 ` Romain Bardou @ 2012-02-13 13:46 ` Török Edwin 2012-02-13 13:53 ` Edgar Friendly 1 sibling, 0 replies; 6+ messages in thread From: Török Edwin @ 2012-02-13 13:46 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] Package installation assumptions made by odb 2012-02-13 13:39 ` Romain Bardou 2012-02-13 13:46 ` Török Edwin @ 2012-02-13 13:53 ` Edgar Friendly 1 sibling, 0 replies; 6+ messages in thread From: Edgar Friendly @ 2012-02-13 13:53 UTC (permalink / raw) To: caml-list 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-13 13:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-11 21:10 [Caml-list] Package installation assumptions made by odb Edgar Friendly 2012-02-13 11:01 ` Arnaud Spiwack 2012-02-13 13:04 ` Edgar Friendly 2012-02-13 13:39 ` Romain Bardou 2012-02-13 13:46 ` Török Edwin 2012-02-13 13:53 ` Edgar Friendly
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox