> - Anil Madhavapeddy, 26/08/2015 18:49 -
> One thing I noticed is that the automatic plugin installation doesn't
> play well with non-interactivity (e.g. -y), btw.

It should work with `OPAMYES=1` ; it's otherwise a bit difficult to parse the 
command-line arguments that are normally directed towards a different program.

Or should we allow something like `opam -y publish` ? Or normalise the 
arguments a plugin is supposed to accept ?

I don't see a very nice solution to this...


> 
> -anil
> 
> > On 19 Aug 2015, at 10:56, Louis Gesbert <[email protected]> wrote:
> > 
> > Allowing plugins with packages named `opam-xxx` in opam 1.3 sure won't cost 
> > much. I don't see a good reason not to add it now even if it can't be used 
> > in a while.
> > 
> >> - Fabrice Le Fessant, 19/08/2015 11:49 -
> >> I think it's worth doing it, even if we also keep the old logic for
> >> compatilibility for a few years from now, until Ubuntu LTS is dead.
> >> Otherwise, we will either have to limit opam plugin names to avoid
> >> conflicts with existing packages (for example, "cache" is already a
> >> package, preventing "opam-cache", etc.), either to reserve names for
> >> possible plugins ("search", "file", "git", etc).
> > 
> > "search" is already an opam command :)
> > 

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel

Reply via email to