[opam-devel] call for help: opam history

[Amir Chaudhry]

Thanks for presenting the overview.  I actually don't really agree with point 1 (the ancestors), nor do I think it's helpful to point out specific differences between OPAM and GODI (at least in this document).

As a relative newcomer to OCaml, I would find it a little odd if much time was spent on other tools that existed before.  Of course, I would expect some brief reference to 'how things were' but this could be covered in a couple of sentences imho.  Since GODI is no longer maintained, any specific comparisons are completely unhelpful to me as it's not an option that I can choose to use — it's not like I'm reading this document in order to make a trade-off between the two.  As a result, it just creates a cognitive burden for me as a reader because in order to understand why OPAM does something, I must first understand how GODI did it.  I'd rather just be told why OPAM does it. Anything more than that feels like unhelpful detail and takes me away from learning about OPAM itself.

What I'd really want from a 'Background' section is a high-level summary of what good things OPAM wanted to keep from previous systems and what problems it wanted to fix (regardless of whatever the tools/systems themselves were).  In other words, the things that would later become OPAM's guiding principles. Paraphrasing from Fabrice's list below (and adding my own) it seem like these are:
- simple user interface
- straightforward (programmer-friendly?) workflow
- Bias towards, extensive automated QA on packages
- 'professional-grade' solvers
- easy to add/update/release new packages

My 2cents :)

Best wishes,
Amir

On 2 Oct 2014, at 10:27, Thomas Gazagnaire <thomas at gazagnaire.org> wrote:

>> Ok. Before modifying the document, I would like to suggest the
>> following overview:
>> 
>> 1/ The Ancestors of OPAM (GODI and so on)
>> 2/ The Foundations of OPAM (gathering several teams to work on OPAM)
>> 3/ The Birth of OPAM (first implementations)
>> 4/ The Rise of OPAM (first release and current situation)
>> 
>> Also, I would like to put some stress on the 4 main differences
>> between GODI and OPAM, as I see them. The 4 short-comings of GODI I
>> see that are fixed by OPAM are:
>> - sub-optimal installation solutions => use of CUDF/Dose
>> - complex user interface => simple "à la apt" interface
>> - complex repository management => simple github-based workflow
>> - no automatic Q/A on the repository => Travis + OWS
>> 
>> What do you think ?
> 
> sounds good to me!
> 
>> --Fabrice
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Sep 30, 2014 at 7:11 PM, Anil Madhavapeddy <anil at recoil.org> wrote:
>>> On 30 Sep 2014, at 18:06, Fabrice Le Fessant <Fabrice.Le_fessant at inria.fr> wrote:
>>>> 
>>>> @Anil: yes, I kind of remember that there was a tool to automatically
>>>> extract the meta-data from GODI packages and to translate it to
>>>> "descr" files. However, the work of filling OPAM files with build and
>>>> install instructions was not automated, to the best of my knowledge,
>>>> so Frederic had to build every package and check that it would work
>>>> well in OPAM. But of course, GODI should be credited, both for
>>>> providing an inspiration for OPAM (we built on the experience we had
>>>> of GODI and sometimes, of the problems we had with it) and for forcing
>>>> many developers to package nicely their programs and libraries, so
>>>> that we work of packaging them again was much more easy.
>>> 
>>> Yes, I think that's right -- it was just the descriptions and metadata
>>> that were borrowed from GODI, with the build instructions being manually
>>> edited to add (e.g.) the prefix and make macros.  That was quite a bit of
>>> work...
>>> 
>>> -anil
>>> 
>> 
>> 
>> 
>> -- 
>> Fabrice LE FESSANT
>> Chercheur en Informatique
>> INRIA Paris Rocquencourt -- OCamlPro
>> Programming Languages and Distributed Systems
> 
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel