Re: AW: [Caml-list] GODI is shutting down

[Markus Mottl <markus.mottl@gmail.com>]

On Wed, Jul 24, 2013 at 10:44 AM, Thomas Gazagnaire <thomas@ocamlpro.com> wrote:
> 6. "No, all package managers should unite in this point, and only accept
> packages with oasis support. (Btw, that's homework for me.) Just do it the
> same way as we did when requiring findlib."
>
> I disagree, people should be free to use whatever system they want.

Let me add here that avoiding limitations or obstacles does not
necessarily create more freedom.  I, as a package developer, want to
have the freedom of not having to worry about annoyances in the
packaging process that are only there so that unlikely alternatives
can be supported.  Lets keep the simple (= standard) things simple
while keeping the non-standard things possible, but I'd prefer
simplicity if there is a conflict.

Oasis may are may not become the standard OCaml package specification
tool, but it is widely used so I think it's fair if it is better
supported by OPAM than alternatives.

> 7. About the generation of OPAM files from _oasis
>
> I am not totally convinced by all the arguments I seen so far. Making a new release because a package constraint is wrong seems not to be a good idea to me. A large proportion of pull request in the the package metadata's repository is about fixing such dependency constraints (which are discovered by our testing tools). I don't have a yet a good story to bring that information back into the package, but I'd say that I'm not very fond of mixing everything together: let's keep the dependency constraints part of the package system and the build instruction part of the build system -- that's much simpler that way.

It's funny that you say that, because this collides with your opinion
on 6).  This would mean forcing people to use OPAM to specify package
version dependencies instead of leaving this information in their
packages.  That's why I think that requiring (or at least
well-supporting) something like Oasis package specifications as
standard adds freedom for package developers.

My guess is that you are not totally happy with Oasis at this point so
this may be a topic to address.  Being an Oasis user, I would say that
the Oasis tools may not be as mature yet as one would hope, but the
Cabal-like package specification syntax seems decent enough to be
supported by OPAM.  It really shouldn't be that hard to automate the
process of updating OPAM metadata (including version constraints)
based on changes in Oasis package specifications.

Regards,
Markus

--
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com