caml-list - the Caml user's mailing list
 help / Atom feed
* [Caml-list] LablGtk3 beta1
@ 2018-12-06  6:33 Jacques Garrigue
  2018-12-06 10:05 ` Louis Gesbert
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Jacques Garrigue @ 2018-12-06  6:33 UTC (permalink / raw)
  To: Mailing List OCaml

Dear LablGtk users,

Due to the planned deprecation of gtksourceview2 in Debian,
we have been working on a stripped down port of LablGtk2 to Gtk-3.

A first beta is available for download at the usual location:
	http://lablgtk.forge.ocamlcore.org
	https://forge.ocamlcore.org/frs/download.php/1769/lablgtk-3.0.beta1.tar.gz

There is no opam package yet, because I’m not sure how to do that:
I seem to need to add a new conf-gtksourceview3 package too, and I’m not
sure how to proceed. Help accepted.

Note that this is not the originally planned introspection based port, but
a manual port of lablgtk2, dropping widgets that are no longer
available. It is of course possible to add new widgets if people
are willing to contribute.

The main goal is to allow application using lablgtksourceview,
such as CoqIDE, to compile on top of Gtk-3. Since Gtk-2 itself
stays available, lablgtk2 will continue to be supported for other
applications.

The code is in the lablgtk3 branch:
	https://github.com/garrigue/lablgtk/tree/lablgtk3
There is an ongoing discussion
	https://github.com/garrigue/lablgtk/issues/2

The current status is that a modified version of CoqIDE compiles
and runs.

Please report issues on GitHub.

Jacques Garrigue

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
@ 2018-12-06 10:05 ` Louis Gesbert
  2018-12-06 10:35 ` Gabriel Scherer
  2018-12-07 10:04 ` Emilio Jesús Gallego Arias
  2 siblings, 0 replies; 19+ messages in thread
From: Louis Gesbert @ 2018-12-06 10:05 UTC (permalink / raw)
  To: caml-list, Jacques Garrigue

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

Hi Jacques,

I'll try to package your branch in a `lablgtk3` opam package, and see if I can run some tests. Thanks for the port!

Louis Gesbert — OCamlPro

> - Jacques Garrigue, 06/12/2018 15:33 -
> Dear LablGtk users,
> 
> Due to the planned deprecation of gtksourceview2 in Debian,
> we have been working on a stripped down port of LablGtk2 to Gtk-3.
> 
> A first beta is available for download at the usual location:
> 	http://lablgtk.forge.ocamlcore.org
> 	https://forge.ocamlcore.org/frs/download.php/1769/lablgtk-3.0.beta1.tar.gz
> 
> There is no opam package yet, because I’m not sure how to do that:
> I seem to need to add a new conf-gtksourceview3 package too, and I’m not
> sure how to proceed. Help accepted.
> 
> Note that this is not the originally planned introspection based port, but
> a manual port of lablgtk2, dropping widgets that are no longer
> available. It is of course possible to add new widgets if people
> are willing to contribute.
> 
> The main goal is to allow application using lablgtksourceview,
> such as CoqIDE, to compile on top of Gtk-3. Since Gtk-2 itself
> stays available, lablgtk2 will continue to be supported for other
> applications.
> 
> The code is in the lablgtk3 branch:
> 	https://github.com/garrigue/lablgtk/tree/lablgtk3
> There is an ongoing discussion
> 	https://github.com/garrigue/lablgtk/issues/2
> 
> The current status is that a modified version of CoqIDE compiles
> and runs.
> 
> Please report issues on GitHub.
> 
> Jacques Garrigue
> 
> 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
  2018-12-06 10:05 ` Louis Gesbert
@ 2018-12-06 10:35 ` Gabriel Scherer
  2018-12-07 10:04 ` Emilio Jesús Gallego Arias
  2 siblings, 0 replies; 19+ messages in thread
From: Gabriel Scherer @ 2018-12-06 10:35 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: caml users

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

> There is no opam package yet, because I’m not sure how to do that:
> I seem to need to add a new conf-gtksourceview3 package too, and I’m not
> sure how to proceed. Help accepted.

The point of conf-* packages is to centralize the logic to check for an
outside-opam dependency (that must be provided by the operating system); if
an installation task fails on a conf-* target, the user should know that
the problem is not their OCaml environment, but a system dependency to
install. Each conf-* package implements its own
external-dependency-detection logic; some packages call pkg-config to check
that a library exist, or even try to build a dummy C program with the
library, but the least they can be expected to do is to check for a list of
"depexts", system packages (one for each distribution / OS package manager)
that contain the dependency.

For conf-gtksourceview3, you should aim to do no worse than
conf-gtksourceview2. The source fo that package can be looked in the
current opam-repository:

https://github.com/ocaml/opam-repository/blob/master/packages/conf-gtksourceview/conf-gtksourceview.2/opam

You can see in the source that it lists some depexts, and also performs a
pkg-config test in its `build` rule.

It should be very easy to port that package into a conf-gtksourceview3
package, replacing what needs to be replaced:
- are the licence and homepage the same?
- what is the name of the pkg-config argument you should pass?
  (I just checked, it is "gtksourceview-3.0")
- what are the name for the gtk3 versions of the system packages?
  You can search the web to find the name of a package for a given
distribution,
  and the links to do this are listed in
    https://github.com/ocaml/opam-depext/blob/master/README.md



On Thu, Dec 6, 2018 at 7:33 AM Jacques Garrigue <
garrigue@math.nagoya-u.ac.jp> wrote:

> Dear LablGtk users,
>
> Due to the planned deprecation of gtksourceview2 in Debian,
> we have been working on a stripped down port of LablGtk2 to Gtk-3.
>
> A first beta is available for download at the usual location:
>         http://lablgtk.forge.ocamlcore.org
>
> https://forge.ocamlcore.org/frs/download.php/1769/lablgtk-3.0.beta1.tar.gz
>
> There is no opam package yet, because I’m not sure how to do that:
> I seem to need to add a new conf-gtksourceview3 package too, and I’m not
> sure how to proceed. Help accepted.
>
> Note that this is not the originally planned introspection based port, but
> a manual port of lablgtk2, dropping widgets that are no longer
> available. It is of course possible to add new widgets if people
> are willing to contribute.
>
> The main goal is to allow application using lablgtksourceview,
> such as CoqIDE, to compile on top of Gtk-3. Since Gtk-2 itself
> stays available, lablgtk2 will continue to be supported for other
> applications.
>
> The code is in the lablgtk3 branch:
>         https://github.com/garrigue/lablgtk/tree/lablgtk3
> There is an ongoing discussion
>         https://github.com/garrigue/lablgtk/issues/2
>
> The current status is that a modified version of CoqIDE compiles
> and runs.
>
> Please report issues on GitHub.
>
> Jacques Garrigue
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> https://inbox.ocaml.org/caml-list
> Forum: https://discuss.ocaml.org/
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
  2018-12-06 10:05 ` Louis Gesbert
  2018-12-06 10:35 ` Gabriel Scherer
@ 2018-12-07 10:04 ` Emilio Jesús Gallego Arias
  2018-12-07 10:25   ` Gabriel Scherer
  2 siblings, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-07 10:04 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: Mailing List OCaml

Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> writes:

> There is no opam package yet, because I’m not sure how to do that:
> I seem to need to add a new conf-gtksourceview3 package too, and I’m not
> sure how to proceed. Help accepted.
>
> Note that this is not the originally planned introspection based port, but
> a manual port of lablgtk2, dropping widgets that are no longer
> available. It is of course possible to add new widgets if people
> are willing to contribute.
>
> The main goal is to allow application using lablgtksourceview,
> such as CoqIDE, to compile on top of Gtk-3. Since Gtk-2 itself
> stays available, lablgtk2 will continue to be supported for other
> applications.

I am not sure I see the advantages of the *-conf solution vs a more
granular approach as done here
https://github.com/garrigue/lablgtk/pull/14, where each package has a
fixed set of system dependencies.

AFAICT `depext` fields can be added to the custom packages just fine,
and they don't have the *-conf pitfall of having to recompile a lot of
dependencies when a *-conf package is installed.

I find more natural to do `opam install lablgtk2-sourceview2` than
`opam install conf-gtksourceview lablgtk2`

E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-07 10:04 ` Emilio Jesús Gallego Arias
@ 2018-12-07 10:25   ` Gabriel Scherer
  2018-12-07 18:34     ` Emilio Jesús Gallego Arias
  0 siblings, 1 reply; 19+ messages in thread
From: Gabriel Scherer @ 2018-12-07 10:25 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias, Jacques Garrigue, caml users

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

> I am not sure I see the advantages of the *-conf solution vs a more
> granular approach [...] where each package has a
> fixed set of system dependencies.

If several OCaml package have system dependencies in common,
(of several versions of the same OCaml package),
indicating depexts per-package duplicate the information. This is what we
were doing before and in practice most package depexts were perpetually
out-of-date.
Some information in the conf-package is rather canonical from system to
system
(such as: the pkg-config name, even though there is still variation
unfortunately),
some is highly system-dependent (the package name in the package manager);
I think it's reasonable to also have the "canonical" information in the
build system.

Also, conf-* packages are very early in the dependency tree, so a pragmatic
advantage
is that they will fail early in the build, typically before you have
installed all the OCaml dependencies
and you start building the package itself.
(Also, depending on the configure/build system, you may geta nice error if
a dependency is missing,
or a crappy compilation failure that can be hard for users to interpret).

> they don't have the *-conf pitfall of having to recompile a lot of
> dependencies when a *-conf package is installed

If you edit a package to update system dependencies, you have the same
recompilation issues.
If you have to recompile *more* in the case of a conf-* package, it is
because it introduced dependency
sharing, which is a good thing -- making the repository more maintainable.


> I find more natural to do `opam install lablgtk2-sourceview2` than
> `opam install conf-gtksourceview lablgtk2`

I don't understand, the point is for lablgtk2-sourceview2 to depend
on conf-gtksourceview2, so you should just use the first command
and the conf-* package(s) will get installed as well.


On Fri, Dec 7, 2018 at 11:04 AM Emilio Jesús Gallego Arias <e@x80.org>
wrote:

> Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> writes:
>
> > There is no opam package yet, because I’m not sure how to do that:
> > I seem to need to add a new conf-gtksourceview3 package too, and I’m not
> > sure how to proceed. Help accepted.
> >
> > Note that this is not the originally planned introspection based port,
> but
> > a manual port of lablgtk2, dropping widgets that are no longer
> > available. It is of course possible to add new widgets if people
> > are willing to contribute.
> >
> > The main goal is to allow application using lablgtksourceview,
> > such as CoqIDE, to compile on top of Gtk-3. Since Gtk-2 itself
> > stays available, lablgtk2 will continue to be supported for other
> > applications.
>
> I am not sure I see the advantages of the *-conf solution vs a more
> granular approach as done here
> https://github.com/garrigue/lablgtk/pull/14, where each package has a
> fixed set of system dependencies.
>
> AFAICT `depext` fields can be added to the custom packages just fine,
> and they don't have the *-conf pitfall of having to recompile a lot of
> dependencies when a *-conf package is installed.
>
> I find more natural to do `opam install lablgtk2-sourceview2` than
> `opam install conf-gtksourceview lablgtk2`
>
> E.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> https://inbox.ocaml.org/caml-list
> Forum: https://discuss.ocaml.org/
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-07 10:25   ` Gabriel Scherer
@ 2018-12-07 18:34     ` Emilio Jesús Gallego Arias
  2018-12-11  3:09       ` Francois Berenger
  0 siblings, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-07 18:34 UTC (permalink / raw)
  To: Gabriel Scherer; +Cc: Jacques Garrigue, caml users

Hi Gabriel,

Gabriel Scherer <gabriel.scherer@gmail.com> writes:

> If several OCaml package have system dependencies in common, (of
> several versions of the same OCaml package), indicating depexts
> per-package duplicate the information. This is what we were doing
> before and in practice most package depexts were perpetually
> out-of-date.
>
> Some information in the conf-package is rather canonical from system
> to system (such as: the pkg-config name, even though there is still
> variation unfortunately), some is highly system-dependent (the package
> name in the package manager); I think it's reasonable to also have the
> "canonical" information in the build system.

Umm, indeed that may make sense very widely used packages, such as `m4`,
etc... I am not sure this makes sense for gtk tho; right now we have:

lablgtk2.opam
lablgtk2-glade.opam
lablgtk2-gnomecanvas.opam
lablgtk2-gspell.opam
lablgtk2-rsvg.opam
lablgtk2-gl.opam
lablgtk2-gnome.opam
lablgtk2-sourceview2.opam

so adding so many conf- packages seems like a nuisance. Also it is
harder for consumers of the library to depend on the right packages;
this is the reason Debian uses this scheme:

liblablgtkmathview-ocaml-dev
liblabltk-ocaml-dev
liblablgl-ocaml-dev
liblablgtk2-gnome-ocaml-dev
liblablgtk-extras-ocaml-dev
liblablgtksourceview2-ocaml-dev
liblablgtk2-gl-ocaml-dev
liblablgtk2-ocaml-dev

I much prefer to depend on `lablgtk-sourceview` than on `lablgtk` and
`conf-gtksourceview`; not to say the issue with the side effects [see
below]

> Also, conf-* packages are very early in the dependency tree, so a
> pragmatic advantage is that they will fail early in the build,
> typically before you have installed all the OCaml dependencies and you
> start building the package itself.  (Also, depending on the
> configure/build system, you may geta nice error if a dependency is
> missing, or a crappy compilation failure that can be hard for users to
> interpret).

In this case the error messages are the same I think. I am not sure the
"early in the build tree" is so important tho.

> If you edit a package to update system dependencies, you have the same
> recompilation issues.  If you have to recompile *more* in the case of
> a conf-* package, it is because it introduced dependency sharing,
> which is a good thing -- making the repository more maintainable.

The thing is that I am coming from a world (Debian) were package builds
are required to be deterministic; what does editing a package to update
system dependencies mean? How is the repository going to be more
maintainable?

For example, in this case, installing `conf-gl` will force the
recompilation of `lablgtk`, and `conf-gl` could be pulled by an
unrelated package.

It seems very wrong to me that this sharing will actually force a
side-effect on a unrelated package.

IMVHO this is very non-standard behavior that I've only seen in OPAM and
makes things less maintenable indeed, for example if you want to have
Debian packages.

> I don't understand, the point is for lablgtk2-sourceview2 to depend
> on conf-gtksourceview2, so you should just use the first command
> and the conf-* package(s) will get installed as well.

I could do that, but what is the point on shipping a fake, empty package
then? `lablgtk2-sourceview2` can handle the dependencies just fine.

An even worse problem is this case: imagine package A and B both depend
on gtksourceview, however package A requires version > 2.10 and package
B version > 2.11.

How can the sharing possibly work here?

Cheers!
E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-07 18:34     ` Emilio Jesús Gallego Arias
@ 2018-12-11  3:09       ` Francois Berenger
  2018-12-11 11:34         ` Louis Gesbert
  2018-12-14 11:38         ` Emilio Jesús Gallego Arias
  0 siblings, 2 replies; 19+ messages in thread
From: Francois Berenger @ 2018-12-11  3:09 UTC (permalink / raw)
  To: caml users; +Cc: caml-list-request

On 08/12/2018 03:34, Emilio Jesús Gallego Arias wrote:
> Hi Gabriel,
> 
> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
> 
>> If several OCaml package have system dependencies in common, (of
>> several versions of the same OCaml package), indicating depexts
>> per-package duplicate the information. This is what we were doing
>> before and in practice most package depexts were perpetually
>> out-of-date.
>> 
>> Some information in the conf-package is rather canonical from system
>> to system (such as: the pkg-config name, even though there is still
>> variation unfortunately), some is highly system-dependent (the package
>> name in the package manager); I think it's reasonable to also have the
>> "canonical" information in the build system.
> 
> Umm, indeed that may make sense very widely used packages, such as 
> `m4`,
> etc... I am not sure this makes sense for gtk tho; right now we have:
> 
> lablgtk2.opam
> lablgtk2-glade.opam
> lablgtk2-gnomecanvas.opam
> lablgtk2-gspell.opam
> lablgtk2-rsvg.opam
> lablgtk2-gl.opam
> lablgtk2-gnome.opam
> lablgtk2-sourceview2.opam
> 
> so adding so many conf- packages seems like a nuisance. Also it is
> harder for consumers of the library to depend on the right packages;
> this is the reason Debian uses this scheme:
> 
> liblablgtkmathview-ocaml-dev
> liblabltk-ocaml-dev
> liblablgl-ocaml-dev
> liblablgtk2-gnome-ocaml-dev
> liblablgtk-extras-ocaml-dev
> liblablgtksourceview2-ocaml-dev
> liblablgtk2-gl-ocaml-dev
> liblablgtk2-ocaml-dev
> 
> I much prefer to depend on `lablgtk-sourceview` than on `lablgtk` and
> `conf-gtksourceview`; not to say the issue with the side effects [see
> below]
> 
>> Also, conf-* packages are very early in the dependency tree, so a
>> pragmatic advantage is that they will fail early in the build,
>> typically before you have installed all the OCaml dependencies and you
>> start building the package itself.  (Also, depending on the
>> configure/build system, you may geta nice error if a dependency is
>> missing, or a crappy compilation failure that can be hard for users to
>> interpret).
> 
> In this case the error messages are the same I think. I am not sure the
> "early in the build tree" is so important tho.
> 
>> If you edit a package to update system dependencies, you have the same
>> recompilation issues.  If you have to recompile *more* in the case of
>> a conf-* package, it is because it introduced dependency sharing,
>> which is a good thing -- making the repository more maintainable.
> 
> The thing is that I am coming from a world (Debian) were package builds
> are required to be deterministic; what does editing a package to update
> system dependencies mean? How is the repository going to be more
> maintainable?
> 
> For example, in this case, installing `conf-gl` will force the
> recompilation of `lablgtk`, and `conf-gl` could be pulled by an
> unrelated package.
> 
> It seems very wrong to me that this sharing will actually force a
> side-effect on a unrelated package.
> 
> IMVHO this is very non-standard behavior that I've only seen in OPAM 
> and
> makes things less maintenable indeed, for example if you want to have
> Debian packages.
> 
>> I don't understand, the point is for lablgtk2-sourceview2 to depend
>> on conf-gtksourceview2, so you should just use the first command
>> and the conf-* package(s) will get installed as well.
> 
> I could do that, but what is the point on shipping a fake, empty 
> package
> then? `lablgtk2-sourceview2` can handle the dependencies just fine.
> 
> An even worse problem is this case: imagine package A and B both depend
> on gtksourceview, however package A requires version > 2.10 and package
> B version > 2.11.

Oh, this one is an interesting question!

You are suggesting that opam should support the installation of 
different versions of the same thing.
I think nix can do that, and that indeed looks like a current limitation 
of opam.

Regards,
F.


-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-11  3:09       ` Francois Berenger
@ 2018-12-11 11:34         ` Louis Gesbert
  2018-12-14 11:41           ` Emilio Jesús Gallego Arias
  2018-12-14 11:38         ` Emilio Jesús Gallego Arias
  1 sibling, 1 reply; 19+ messages in thread
From: Louis Gesbert @ 2018-12-11 11:34 UTC (permalink / raw)
  To: caml-list, Francois Berenger; +Cc: caml-list-request

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

> > An even worse problem is this case: imagine package A and B both depend
> > on gtksourceview, however package A requires version > 2.10 and package
> > B version > 2.11.
> 
> Oh, this one is an interesting question!
> 
> You are suggesting that opam should support the installation of 
> different versions of the same thing.
> I think nix can do that, and that indeed looks like a current limitation 
> of opam.

It is a limitation that has been explicitely put into opam, because of what the rest of the tooling requires. I made a more detailed explanation here: https://github.com/ocaml/opam/issues/3696

I don't believe that's what was suggested in the original message, though ? The pointed issue seemed to me that we don't handle detailed versions for `conf-*` packages, which means we can't encode precise dependencies to the underlying system package versions. In other words, _handling_ the fact that "package A requires version > 2.10 and package B version > 2.11" is no problem at all for opam, but _expressing_ it is, for `conf-*` packages.

The thing is that we can only detect the installed versions of system packages, not control them (even with `opam-depext`, we can trigger the installation of a given package, but most distributions don't allow to choose between multiple versions). In this case, you will have to rely on your package's `./configure` to fail when the version of the system dependency doesn't match, which is not the most helpful solution; adding the depexts to the package directly could help a bit, but again, as we don't control the system package version anyway, not that much.

There is one way we could improve a (little) bit: e.g. `conf-gtksourceview` could expose¹ a `system-version` variable upon installation, e.g. `2.11`, and then you could fail explicitely with a message directly from the opam file, without relying on `./configure` (it will still fail only at build time, though, because the value of the variable can't be known yet at resolution time).

Hope this helps,
Louis Gesbert — OCamlPro

¹ http://opam.ocaml.org/doc/Manual.html#dotconfigsection-variables

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-11  3:09       ` Francois Berenger
  2018-12-11 11:34         ` Louis Gesbert
@ 2018-12-14 11:38         ` Emilio Jesús Gallego Arias
  2018-12-16  8:12           ` Jacques Garrigue
  1 sibling, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-14 11:38 UTC (permalink / raw)
  To: Francois Berenger; +Cc: caml users, caml-list-request

Hi Francois,

Francois Berenger <mlists@ligand.eu> writes:

> You are suggesting that opam should support the installation of
> different versions of the same thing.
> I think nix can do that, and that indeed looks like a current
> limitation of opam.

I wasn't going that far [as that tends to be quite complicated
technically].

I just proposed that our OPAM workflow should support for packages to
specify versioned dependencies on depext stuff, so a package A can do
"gtk-3.0 >= 3.12" and some other package B can specify "gtk-3.0 >=
3.14".

Even if that only serves as documentation for now.

The `conf-gtk` approach seems not very well suited for this.

E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-11 11:34         ` Louis Gesbert
@ 2018-12-14 11:41           ` Emilio Jesús Gallego Arias
  0 siblings, 0 replies; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-14 11:41 UTC (permalink / raw)
  To: Louis Gesbert; +Cc: caml-list, Francois Berenger, caml-list-request

Louis Gesbert <louis.gesbert@ocamlpro.com> writes:

> I don't believe that's what was suggested in the original message,
> though ? The pointed issue seemed to me that we don't handle detailed
> versions for `conf-*` packages, which means we can't encode precise
> dependencies to the underlying system package versions. In other
> words, _handling_ the fact that "package A requires version > 2.10 and
> package B version > 2.11" is no problem at all for opam, but
> _expressing_ it is, for `conf-*` packages.

Exactly, thanks for the summary Louis.

> The thing is that we can only detect the installed versions of system
> packages, not control them (even with `opam-depext`, we can trigger
> the installation of a given package, but most distributions don't
> allow to choose between multiple versions). In this case, you will
> have to rely on your package's `./configure` to fail when the version
> of the system dependency doesn't match, which is not the most helpful
> solution; adding the depexts to the package directly could help a bit,
> but again, as we don't control the system package version anyway, not
> that much.
>
> There is one way we could improve a (little) bit:
> e.g. `conf-gtksourceview` could expose¹ a `system-version` variable
> upon installation, e.g. `2.11`, and then you could fail explicitely
> with a message directly from the opam file, without relying on
> `./configure` (it will still fail only at build time, though, because
> the value of the variable can't be known yet at resolution time).

I am still not convinced by this; it seems to require quite a bit of
overhead for something that is IMO better done on the package itself.

The thing is that packages are the ones that really know what they
depend upon; adding this indirection layer serves little purpose.

Something that should be very useful tho is to be able to rely on a
centralized depexp database.

Thus, when I write "depext: [ gtk-2.0 >= 2.11 ]" I don't have to provide
the info for native mappings, and I can check what the supported set of
names is, etc...

Best,
E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-14 11:38         ` Emilio Jesús Gallego Arias
@ 2018-12-16  8:12           ` Jacques Garrigue
  2018-12-17 12:11             ` Emilio Jesús Gallego Arias
  0 siblings, 1 reply; 19+ messages in thread
From: Jacques Garrigue @ 2018-12-16  8:12 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias; +Cc: Mailing List OCaml

2018/12/14 20:38, Emilio Jesús Gallego Arias <e@x80.org>:
> 
> Hi Francois,
> 
> Francois Berenger <mlists@ligand.eu> writes:
> 
>> You are suggesting that opam should support the installation of
>> different versions of the same thing.
>> I think nix can do that, and that indeed looks like a current
>> limitation of opam.
> 
> I wasn't going that far [as that tends to be quite complicated
> technically].
> 
> I just proposed that our OPAM workflow should support for packages to
> specify versioned dependencies on depext stuff, so a package A can do
> "gtk-3.0 >= 3.12" and some other package B can specify "gtk-3.0 >=
> 3.14".
> 
> Even if that only serves as documentation for now.
> 
> The `conf-gtk` approach seems not very well suited for this.

Emilio, I do agree with you on that.
I added a conf-gtk3 as was suggested to me, and since lablgtk3 requires
gtk 3.18, if dependes on a versioned package conf-gtk3.18 (i.e. cong-gtk3 ">= 18”)
However, if somebody else introduces a conf-gtk3.22 version, that one will
be installed by default (even for lablgtk3), and fail if one gtk-3.18 is available,
so this does not seem to be the right solution for versioning, and I see no
other way to do it with the current opam.

Jacques


-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-16  8:12           ` Jacques Garrigue
@ 2018-12-17 12:11             ` Emilio Jesús Gallego Arias
  2018-12-18 14:33               ` David Allsopp
  0 siblings, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-17 12:11 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: Mailing List OCaml

Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> writes:

> Emilio, I do agree with you on that.

> I added a conf-gtk3 as was suggested to me, and since lablgtk3 requires
> gtk 3.18, if dependes on a versioned package conf-gtk3.18 (i.e. cong-gtk3 ">= 18”)
> However, if somebody else introduces a conf-gtk3.22 version, that one will
> be installed by default (even for lablgtk3), and fail if one gtk-3.18 is available,
> so this does not seem to be the right solution for versioning, and I see no
> other way to do it with the current opam.

Indeed, IMVHO lablgtk should follow the packaging structure hinted at
https://github.com/garrigue/lablgtk/pull/14 and don't depend on
`conf-gtk`.

This would have the important additional benefit of allowing fully
automatic OPAM releases, which are trickier to do when the conf-foo
package is there.

E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: [Caml-list] LablGtk3 beta1
  2018-12-17 12:11             ` Emilio Jesús Gallego Arias
@ 2018-12-18 14:33               ` David Allsopp
  2018-12-19  1:20                 ` Emilio Jesús Gallego Arias
  0 siblings, 1 reply; 19+ messages in thread
From: David Allsopp @ 2018-12-18 14:33 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias, Jacques Garrigue; +Cc: Mailing List OCaml

Emilio Jesús Gallego Arias wrote:
> Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> writes:
> 
> > Emilio, I do agree with you on that.
> 
> > I added a conf-gtk3 as was suggested to me, and since lablgtk3
> > requires gtk 3.18, if dependes on a versioned package conf-gtk3.18
> > (i.e. cong-gtk3 ">= 18”) However, if somebody else introduces a
> > conf-gtk3.22 version, that one will be installed by default (even for
> > lablgtk3), and fail if one gtk-3.18 is available, so this does not
> > seem to be the right solution for versioning, and I see no other way to
> do it with the current opam.
> 
> Indeed, IMVHO lablgtk should follow the packaging structure hinted at
> https://github.com/garrigue/lablgtk/pull/14 and don't depend on `conf-
> gtk`.
> 
> This would have the important additional benefit of allowing fully
> automatic OPAM releases, which are trickier to do when the conf-foo
> package is there.

If I may, there seems to be a little bit of "throwing the baby out with the bath water" where the conf- packages are concerned. It's also worth remembering that the layout of a package in opam-repository is the concern of opam-repository's maintainers (I'm not one, btw), not necessarily packagers.

At present, it is indeed not possible in opam to depend on the versions of system packages (with the exception of OCaml). The only way, without new support, is to mirror all the releases - as is done for the ocaml package - but that's likely to be a real PITA to maintain, and overkill.

However, the conf package remains the only place in which the depext information (i.e. OS-dependent packages) should be. Anything else involves duplication and so is fundamentally not a better solution.

I do have one question, as I know comparatively little about distributions of GTK itself - if on any system I request gtk3 and I get, say, gtk 3.17 then on most systems, what would I need to do to get gtk 3.18? Is it easy? For example, if I'm on Ubuntu 16.04 and I want gtk3 3.20, it looks quite tricky to achieve that, I think?

If it's the case that the user is most likely stuck with the version on their system and cannot easily change it, then it looks to me as though this should really have been conf-gtk3.0 which simply installs whatever is available (no minimum version check) and then the lablgtk packages should check the version and fail their *build* if the version isn't recent enough.

The other option is still to have conf-gtk3.0 do whatever is necessary to install gtk3 on the system and then have an entirely separate conf-gtk318 package which encodes the ">= 3.18" check - that has the benefit of centralising OS-specific version probing. You would then add an entirely separate conf-gtk322 package if someone else needed the ">= 3.22" check. That's not terribly elegant or scalable, but would be a reasonable workaround for the few specific packages where this matters, prior to opam being able to include dependency on available versions of system packages.


David

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-18 14:33               ` David Allsopp
@ 2018-12-19  1:20                 ` Emilio Jesús Gallego Arias
  2018-12-19 10:15                   ` David Allsopp
  0 siblings, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-19  1:20 UTC (permalink / raw)
  To: David Allsopp; +Cc: Jacques Garrigue, Mailing List OCaml

Hi David,

> If I may, there seems to be a little bit of "throwing the baby out
> with the bath water" where the conf- packages are concerned.

Well, to me it means more like two solutions with different tradeoffs,
and I think the no-conf package solution seems to have a better one
IMVHO.

A kind of "warning light" for me is that none of the packaging systems I
know [admittedly little more than Debian] have this notion of
"conf-package", but rather, packages do depend on what they need.

This approach is well-tested and understood thus I feel more confident
with it, but of course I have a Debian background.

> It's also worth remembering that the layout of a package in
> opam-repository is the concern of opam-repository's maintainers (I'm
> not one, btw), not necessarily packagers.

What does this mean in practice? Is there some official policy [such as
the Debian Policy] to follow?

> At present, it is indeed not possible in opam to depend on the
> versions of system packages (with the exception of OCaml). The only
> way, without new support, is to mirror all the releases - as is done
> for the ocaml package - but that's likely to be a real PITA to
> maintain, and overkill.

I guess that the dependency on system vs opam packages seems a bit
artificial to me. If a package depends on "foo", it should not matter
much to the declarative package specification where is "foo" coming
from.

> However, the conf package remains the only place in which the depext
> information (i.e. OS-dependent packages) should be. Anything else
> involves duplication and so is fundamentally not a better solution.

I don't see where the duplication is. In one case you do:

depends: [ "conf-gtk3.0" >= ... ]

and in the other

depext: [ "gtk3.0" >= ... ]

Indeed the depext repository should contain a centralized database of
depext mappings.

> I do have one question, as I know comparatively little about
> distributions of GTK itself - if on any system I request gtk3 and I
> get, say, gtk 3.17 then on most systems, what would I need to do to
> get gtk 3.18? Is it easy? For example, if I'm on Ubuntu 16.04 and I
> want gtk3 3.20, it looks quite tricky to achieve that, I think?

In Debian-based systems getting a new release of GTK usually involves a
new major OS version; minor upgrades may be possible tho but they are
tricky.

However if the GTK version you want is ABI compatible you can indeed
backport the package without too much trouble, tho something as complex
as GTK is likely to create "suprises".

> If it's the case that the user is most likely stuck with the version
> on their system and cannot easily change it, then it looks to me as
> though this should really have been conf-gtk3.0 which simply installs
> whatever is available (no minimum version check) and then the lablgtk
> packages should check the version and fail their *build* if the
> version isn't recent enough.

The thing is then what's the point on having a conf package. It seems
like an unnecessary indirection layer. I'd rather depend on GTK itself,
as this way I get a full automated release/management workflow.

As we discussed in the other thread, conf packages seem to have a very
unpleasant property if coupled with something such as lablgtk; if they
are not 1:1 then a change in lablgtk may require a change in conf-gtk
which may in turn break an unrelated, depending package.

If they are 1:1, then the indirection seems unnecessary [at the package
level]

> The other option is still to have conf-gtk3.0 do whatever is necessary
> to install gtk3 on the system and then have an entirely separate
> conf-gtk318 package which encodes the ">= 3.18" check - that has the
> benefit of centralising OS-specific version probing. You would then
> add an entirely separate conf-gtk322 package if someone else needed
> the ">= 3.22" check. That's not terribly elegant or scalable, but
> would be a reasonable workaround for the few specific packages where
> this matters, prior to opam being able to include dependency on
> available versions of system packages.

Well that seems even worse I'd dare to say; more coupling and more
packages is going to be worse, I think.

Having dependencies on depext would be a cool improvement, but that's
not necessary to have today IMHO in order to have a self-contained
lablgtk package.

Removing duplication of dexpext mappings would indeed be an extremely
welcome thing. [I was under the impression that this was already
implemented but I am not sure anymore]

Cheers,
E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: [Caml-list] LablGtk3 beta1
  2018-12-19  1:20                 ` Emilio Jesús Gallego Arias
@ 2018-12-19 10:15                   ` David Allsopp
  2018-12-19 11:13                     ` Emilio Jesús Gallego Arias
  0 siblings, 1 reply; 19+ messages in thread
From: David Allsopp @ 2018-12-19 10:15 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias; +Cc: Jacques Garrigue, Mailing List OCaml

Emilio Jesús Gallego Arias wrote:
> Hi David,
> 
> > If I may, there seems to be a little bit of "throwing the baby out
> > with the bath water" where the conf- packages are concerned.
> 
> Well, to me it means more like two solutions with different tradeoffs, and
> I think the no-conf package solution seems to have a better one IMVHO.

My opinion is less humble - unnecessary duplication and having to maintain the same info in n places vs in 1 place is not a trade-off! :)

> A kind of "warning light" for me is that none of the packaging systems I
> know [admittedly little more than Debian] have this notion of "conf-
> package", but rather, packages do depend on what they need.
> 
> This approach is well-tested and understood thus I feel more confident
> with it, but of course I have a Debian background.

This is an apples vs oranges comparison - Debian (i.e. apt) only has to worry about what apt can install. Imagine instead an apt package which has to depend on being able to install a dependency from either yum, nix, brew, chocolatey, ... oh, and they put your dependency in different combinations of packages *and* use different version systems... oh, and on Windows, opam may choose to download the C sources for GTK3 and build them (in opam)...

> > It's also worth remembering that the layout of a package in
> > opam-repository is the concern of opam-repository's maintainers (I'm
> > not one, btw), not necessarily packagers.
> 
> What does this mean in practice? Is there some official policy [such as
> the Debian Policy] to follow?

I don't think there's (yet) a formally written down policy - but there is the existence of those conf- packages (i.e. the chameleon principle - "do it like everyone else seems to be doing") and the comments of the maintainers expressing the desire for their use (and occasionally editing packages themselves to do it...)

> > At present, it is indeed not possible in opam to depend on the
> > versions of system packages (with the exception of OCaml). The only
> > way, without new support, is to mirror all the releases - as is done
> > for the ocaml package - but that's likely to be a real PITA to
> > maintain, and overkill.
> 
> I guess that the dependency on system vs opam packages seems a bit
> artificial to me. If a package depends on "foo", it should not matter much
> to the declarative package specification where is "foo" coming from.

The solver needs to be aware of the universe of possible versions in order to be able to select (more below). It's not artificial - it just depends on how big you want your package universe to be and, rather more importantly, where you get the details of it from.

> > However, the conf package remains the only place in which the depext
> > information (i.e. OS-dependent packages) should be. Anything else
> > involves duplication and so is fundamentally not a better solution.
> 
> I don't see where the duplication is. In one case you do:
> 
> depends: [ "conf-gtk3.0" >= ... ]
> 
> and in the other
> 
> depext: [ "gtk3.0" >= ... ]
> 
> Indeed the depext repository should contain a centralized database of
> depext mappings.

Your centralized database literally is the conf package - it already exists, there's no need for a change. You are proposing replacing the multiple entries in depext filtered by os-distribution with a single entry called gtk3.0 and having a central repository which has the os-distribution specific meanings of "gtk3.0" - it's the same thing.

The mistake in what you're describing is *how* it is possible to map a version constraint.

> > I do have one question, as I know comparatively little about
> > distributions of GTK itself - if on any system I request gtk3 and I
> > get, say, gtk 3.17 then on most systems, what would I need to do to
> > get gtk 3.18? Is it easy? For example, if I'm on Ubuntu 16.04 and I
> > want gtk3 3.20, it looks quite tricky to achieve that, I think?
> 
> In Debian-based systems getting a new release of GTK usually involves a
> new major OS version; minor upgrades may be possible tho but they are
> tricky.
> 
> However if the GTK version you want is ABI compatible you can indeed
> backport the package without too much trouble, tho something as complex as
> GTK is likely to create "suprises".

This confirms my original suspicion - the conf-gtk3 package should absolutely not be encoding the version test of GTK3, it should simply install it and just have an ultra-simple check that it works (like the other conf packages).

In terms of the versioning problem, opam has two notions for selecting between different packages - dependency and availability. Availability is things about your environment (e.g. os, architecture and, prior to opam 2, OCaml version). Availability is a static check, used to eliminate packages from consideration by the solver. Dependency is dealt with by the solver, and results in a choice between multiple *buildable/installable* packages. It makes no sense for conf-gtk3 to have multiple versions of the package (i.e. for dependency) if you cannot actually install them - this is the problem described in the thread, but the conclusion should have been to stop trying to put the version test in conf-gtk3, not accuse conf- packages of being a broken concept.

What is really needed is a hybrid kind of availability test which could indeed be encoded as a version on the depext specification (that version check would still need to be os-dependent). This I know is being considered already, but it is quite a large change in the solver architecture, since as far I can see it either requires multi-stage solving (which is something we've really tried to avoid in opam) or much deeper querying of the OS package manager to get what is available and what could be available. Essentially, this would generalise even further the configuration which exists to detect your system OCaml compiler's version. 

> > If it's the case that the user is most likely stuck with the version
> > on their system and cannot easily change it, then it looks to me as
> > though this should really have been conf-gtk3.0 which simply installs
> > whatever is available (no minimum version check) and then the lablgtk
> > packages should check the version and fail their *build* if the
> > version isn't recent enough.
> 
> The thing is then what's the point on having a conf package. It seems like
> an unnecessary indirection layer. I'd rather depend on GTK itself, as this
> way I get a full automated release/management workflow.

In order to depend on GTK you need a notion, in opam, of what "depend on GTK" means, and that notion is OS-, and even distribution-, specific - so it gets wrapped in the conf-gtk3 package. We can now say "in opam, to depend on GTK you depend on the conf-gtk3 package", and you no longer have to worry about OSes beyond your own (knowledge). 

> As we discussed in the other thread, conf packages seem to have a very
> unpleasant property if coupled with something such as lablgtk; if they are
> not 1:1 then a change in lablgtk may require a change in conf-gtk which
> may in turn break an unrelated, depending package.
> 
> If they are 1:1, then the indirection seems unnecessary [at the package
> level]

As far as I can see, this is based on an incorrect notion of where lablgtk should be detecting the version of GTK which is installed - it should not be encoded in the conf-gtk3 package, as I elaborated below...

> > The other option is still to have conf-gtk3.0 do whatever is necessary
> > to install gtk3 on the system and then have an entirely separate
> > conf-gtk318 package which encodes the ">= 3.18" check - that has the
> > benefit of centralising OS-specific version probing. You would then
> > add an entirely separate conf-gtk322 package if someone else needed
> > the ">= 3.22" check. That's not terribly elegant or scalable, but
> > would be a reasonable workaround for the few specific packages where
> > this matters, prior to opam being able to include dependency on
> > available versions of system packages.
> 
> Well that seems even worse I'd dare to say; more coupling and more
> packages is going to be worse, I think.
> 
> Having dependencies on depext would be a cool improvement, but that's not
> necessary to have today IMHO in order to have a self-contained lablgtk
> package.

Again, I'm not very clear on what about the conf-gtk3 package makes you feel that lablgtk3 then becomes less "self-contained".

> Removing duplication of dexpext mappings would indeed be an extremely
> welcome thing. [I was under the impression that this was already
> implemented but I am not sure anymore]

Again, duplication of depext mappings is already removed - that's what we use conf packages for...


David

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-19 10:15                   ` David Allsopp
@ 2018-12-19 11:13                     ` Emilio Jesús Gallego Arias
  2018-12-19 11:50                       ` David Allsopp
  0 siblings, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-19 11:13 UTC (permalink / raw)
  To: David Allsopp; +Cc: Jacques Garrigue, Mailing List OCaml

Hi David,

David Allsopp <dra-news@metastack.com> writes:

> My opinion is less humble - unnecessary duplication and having to
> maintain the same info in n places vs in 1 place is not a trade-off!
> :)

Sorry David I don't follow, but I don't see where the "n" copies gets
introduced in the approach I propose, could you provide an example?

> I don't think there's (yet) a formally written down policy - but there
> is the existence of those conf- packages (i.e. the chameleon principle
> - "do it like everyone else seems to be doing") and the comments of
> the maintainers expressing the desire for their use (and occasionally
> editing packages themselves to do it...)

I am not sure I can declare myself a fan of the "chameleon" principle :)
Indeed here I am talking as a "packager", so I guess I have different
tradeoffs.

> The solver needs to be aware of the universe of possible versions in
> order to be able to select (more below). It's not artificial - it just
> depends on how big you want your package universe to be and, rather
> more importantly, where you get the details of it from.

Both approaches add 1 package to the dependency tree, right?

> Your centralized database literally is the conf package - it already
> exists, there's no need for a change. You are proposing replacing the
> multiple entries in depext filtered by os-distribution with a single
> entry called gtk3.0 and having a central repository which has the
> os-distribution specific meanings of "gtk3.0" - it's the same thing.

I was talking under the assumption that we want to be able to express
the desired GTK version on the opam file itself. This is where the conf-
packages seem to not to work so well.

If we don't care about including versioned dependencies on GTK, as you
propose below, then indeed things are different.

> This confirms my original suspicion - the conf-gtk3 package should
> absolutely not be encoding the version test of GTK3, it should simply
> install it and just have an ultra-simple check that it works (like the
> other conf packages).

> but the conclusion should have been to stop trying to put the version
> test in conf-gtk3, not accuse conf- packages of being a broken
> concept.

> In order to depend on GTK you need a notion, in opam, of what "depend
> on GTK" means, and that notion is OS-, and even distribution-,
> specific - so it gets wrapped in the conf-gtk3 package. We can now say
> "in opam, to depend on GTK you depend on the conf-gtk3 package", and
> you no longer have to worry about OSes beyond your own (knowledge).

The origin of the discussion was indeed to inform OPAM about the GTK
version needed by lablgtk.

If we forget about versioning of system deps, then things are OK I
guess, but that seems like not the best user experience.

If I understand correctly then, as of today I could provide 2 lablgtk
opam packages, one depending on conf-gtk3, and one not depending on it,
and the user would actually have the same experience in the case of an
incorrect gtk version, right?

I can see the value on the conf-package today, but for subsystems that
are intrinsically versioned the approach doesn't seem to scale.

>> Having dependencies on depext would be a cool improvement, but that's not
>> necessary to have today IMHO in order to have a self-contained lablgtk
>> package.
>
> Again, I'm not very clear on what about the conf-gtk3 package makes
> you feel that lablgtk3 then becomes less "self-contained".

It is not clear to me who should maintain the conf packages. If I
imagine myself as a packager of lablgtk indeed I cannot then produce
working packages, worse, by depending on conf-gtk3 I cannot even
guarantee that my packages will be installable :(

E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: [Caml-list] LablGtk3 beta1
  2018-12-19 11:13                     ` Emilio Jesús Gallego Arias
@ 2018-12-19 11:50                       ` David Allsopp
  2018-12-19 16:41                         ` Emilio Jesús Gallego Arias
  0 siblings, 1 reply; 19+ messages in thread
From: David Allsopp @ 2018-12-19 11:50 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias; +Cc: Jacques Garrigue, Mailing List OCaml

Emilio Jesús Gallego Arias <e@x80.org> wrote:
> David Allsopp <dra-news@metastack.com> writes:
> 
> > My opinion is less humble - unnecessary duplication and having to
> > maintain the same info in n places vs in 1 place is not a trade-off!
> > :)
> 
> Sorry David I don't follow, but I don't see where the "n" copies gets
> introduced in the approach I propose, could you provide an example?

You were advocating putting the depext information (as required at the moment - with lots of os-specific package names) on the lablgtk3 package. n in my case is every package which also wants to depend on the GTK3 library, which would have to duplicate that same depext information. Granted, at the moment n = 1, but that's not really the point.

Even if you carve the OS-specific package names off somewhere else, "gtk3 >= 3.18" is not guaranteed to be how you'd express that on all platforms, so that notion also probably needs to be centralised too (one word: backports). 

> > I don't think there's (yet) a formally written down policy - but there
> > is the existence of those conf- packages (i.e. the chameleon principle
> > - "do it like everyone else seems to be doing") and the comments of
> > the maintainers expressing the desire for their use (and occasionally
> > editing packages themselves to do it...)
> 
> I am not sure I can declare myself a fan of the "chameleon" principle :)
> Indeed here I am talking as a "packager", so I guess I have different
> tradeoffs.
> 
> > The solver needs to be aware of the universe of possible versions in
> > order to be able to select (more below). It's not artificial - it just
> > depends on how big you want your package universe to be and, rather
> > more importantly, where you get the details of it from.
> 
> Both approaches add 1 package to the dependency tree, right?

No - depexts are not part of the dependency tree for the solver, they're metadata for a package which has already been selected by the solver - that's why version constraints on them are harder to achieve, because the packages have already been selected.

> > Your centralized database literally is the conf package - it already
> > exists, there's no need for a change. You are proposing replacing the
> > multiple entries in depext filtered by os-distribution with a single
> > entry called gtk3.0 and having a central repository which has the
> > os-distribution specific meanings of "gtk3.0" - it's the same thing.
> 
> I was talking under the assumption that we want to be able to express the
> desired GTK version on the opam file itself. This is where the conf-
> packages seem to not to work so well.
>
> If we don't care about including versioned dependencies on GTK, as you
> propose below, then indeed things are different.

Well, it's so much caring, as being able to! It's just not that the conf- packages are not working well - they're doing exactly what they're supposed to, they just can't do what you'd like them additionally to do.

> > This confirms my original suspicion - the conf-gtk3 package should
> > absolutely not be encoding the version test of GTK3, it should simply
> > install it and just have an ultra-simple check that it works (like the
> > other conf packages).
> 
> > but the conclusion should have been to stop trying to put the version
> > test in conf-gtk3, not accuse conf- packages of being a broken
> > concept.
> 
> > In order to depend on GTK you need a notion, in opam, of what "depend
> > on GTK" means, and that notion is OS-, and even distribution-,
> > specific - so it gets wrapped in the conf-gtk3 package. We can now say
> > "in opam, to depend on GTK you depend on the conf-gtk3 package", and
> > you no longer have to worry about OSes beyond your own (knowledge).
> 
> The origin of the discussion was indeed to inform OPAM about the GTK
> version needed by lablgtk.
> 
> If we forget about versioning of system deps, then things are OK I guess,
> but that seems like not the best user experience.

Indeed, but let's not forget that the user experience if they don't have GTK3 >= 3.18 is fundamentally bad, so it's just about making opam tell the user as politely as possible that their system is too old.

It does look to me, until something neater gets added to opam, that your best way forwards is the split I propose to have conf-gtk3 holding the depext installation instructions and then having the extra package for the constraint. I wonder if a new convention for conf-at-least-gtk3-18 or something would do for now.

> If I understand correctly then, as of today I could provide 2 lablgtk opam
> packages, one depending on conf-gtk3, and one not depending on it, and the
> user would actually have the same experience in the case of an incorrect
> gtk version, right?

No - unless you mean that the two lablgtk packages would have different names? One of them must fundamentally have a higher version number than the other, and the one which depends on conf-gtk3 is always going to attempt to install it - opam won't magically fall back to the other one.

> I can see the value on the conf-package today, but for subsystems that are
> intrinsically versioned the approach doesn't seem to scale.

Indeed - although IIRC it doesn't affect any other conf- packages, at least yet. So can we conclude that having two conf- packages for now is superior to leaving all that information permanently embedded just in lablgtk3?

> >> Having dependencies on depext would be a cool improvement, but that's
> >> not necessary to have today IMHO in order to have a self-contained
> >> lablgtk package.
> >
> > Again, I'm not very clear on what about the conf-gtk3 package makes
> > you feel that lablgtk3 then becomes less "self-contained".
> 
> It is not clear to me who should maintain the conf packages. If I imagine
> myself as a packager of lablgtk indeed I cannot then produce working
> packages, worse, by depending on conf-gtk3 I cannot even guarantee that my
> packages will be installable :(

Nothing prevents the maintainer of lablgtk3 also being the maintainer of conf-gtk3 and conf-at-least-gtk3-18 (or whatever). If one chooses just to maintain lablgtk3 and depend on conf-gtk3 then the installability of that is the concern of opam-repository maintainers - that's what we have CI for. Someone else who proposes a change to conf-gtk3 which breaks lablgtk3 would be unable to get their PR merged without in some way fixing lablgtk3. You seem happy that the ocamlfind package is maintained by someone else. I mention it because the opam package for ocamlfind is not (and I don't think ever has) been maintained by ocamlfind's author...


David

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [Caml-list] LablGtk3 beta1
  2018-12-19 11:50                       ` David Allsopp
@ 2018-12-19 16:41                         ` Emilio Jesús Gallego Arias
  2018-12-20 11:33                           ` David Allsopp
  0 siblings, 1 reply; 19+ messages in thread
From: Emilio Jesús Gallego Arias @ 2018-12-19 16:41 UTC (permalink / raw)
  To: David Allsopp; +Cc: Jacques Garrigue, Mailing List OCaml

David Allsopp <dra-news@metastack.com> writes:

> You were advocating putting the depext information (as required at the
> moment - with lots of os-specific package names) on the lablgtk3
> package. n in my case is every package which also wants to depend on
> the GTK3 library, which would have to duplicate that same depext
> information. Granted, at the moment n = 1, but that's not really the
> point.

Ah, indeed sorry I was not clear; indeed what I was thinking is about a
model where the os-dependent information is centralized, but not by
using a package, but a proper database of mappings / recipes.

So indeed maybe the core question is whether using "dummy" package for
capturing this is the best abstraction.

> Even if you carve the OS-specific package names off somewhere else,
> "gtk3 >= 3.18" is not guaranteed to be how you'd express that on all
> platforms, so that notion also probably needs to be centralised too
> (one word: backports).

Indeed that's a problem; I would say that OPAM could talk about upstream
version, but in some cases that may not be enough. But this is something
the current model cannot do very accurately either, right?

[Like if for example two packages A, B depend on gtk where A needs GTK >=
 3.18-4 and B needs 3.20-2 where -x is the Debian version]

> No - depexts are not part of the dependency tree for the solver,
> they're metadata for a package which has already been selected by the
> solver - that's why version constraints on them are harder to achieve,
> because the packages have already been selected.

I meant that depexts are not, however the `conf- package is. So if we
need 1 conf- package for each depext that doesn't seem to be a huge
improvement right?

> Well, it's so much caring, as being able to! It's just not that the
> conf- packages are not working well - they're doing exactly what
> they're supposed to, they just can't do what you'd like them
> additionally to do.

Sure, I was being concerned for user experience with `conf-gtk` where
the package can be installed but the bounds are not the right ones.

>> If I understand correctly then, as of today I could provide 2 lablgtk opam
>> packages, one depending on conf-gtk3, and one not depending on it, and the
>> user would actually have the same experience in the case of an incorrect
>> gtk version, right?
>
> No - unless you mean that the two lablgtk packages would have
> different names? One of them must fundamentally have a higher version
> number than the other, and the one which depends on conf-gtk3 is
> always going to attempt to install it - opam won't magically fall back
> to the other one.

Sorry for the bad explanation. I meant to provide them "in parallel",
like I could package lablgtk in this way or in that other way. Both of
them would fail in the same way.

> Indeed - although IIRC it doesn't affect any other conf- packages, at
> least yet. So can we conclude that having two conf- packages for now
> is superior to leaving all that information permanently embedded just
> in lablgtk3?

I am still not sure the release workflow is superior: we'd have to
introduce 8 additional conf- packages, and we'd have to maintain the
OS-dependent info in the repos anyways.

> Nothing prevents the maintainer of lablgtk3 also being the maintainer
> of conf-gtk3 and conf-at-least-gtk3-18 (or whatever). If one chooses
> just to maintain lablgtk3 and depend on conf-gtk3 then the
> installability of that is the concern of opam-repository maintainers -
> that's what we have CI for. Someone else who proposes a change to
> conf-gtk3 which breaks lablgtk3 would be unable to get their PR merged
> without in some way fixing lablgtk3. You seem happy that the ocamlfind
> package is maintained by someone else. I mention it because the opam
> package for ocamlfind is not (and I don't think ever has) been
> maintained by ocamlfind's author...

I am trying to move all the OCaml software I work on to Dune +
dune-release, thus in the future indeed packages will be maintained
in-tree [by however takes care of the build system]

Best,
E.

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

* RE: [Caml-list] LablGtk3 beta1
  2018-12-19 16:41                         ` Emilio Jesús Gallego Arias
@ 2018-12-20 11:33                           ` David Allsopp
  0 siblings, 0 replies; 19+ messages in thread
From: David Allsopp @ 2018-12-20 11:33 UTC (permalink / raw)
  To: Emilio Jesús Gallego Arias; +Cc: Jacques Garrigue, Mailing List OCaml

Emilio Jesús Gallego Arias <e@x80.org> wrote:
> David Allsopp <dra-news@metastack.com> writes:
> 
> > You were advocating putting the depext information (as required at the
> > moment - with lots of os-specific package names) on the lablgtk3
> > package. n in my case is every package which also wants to depend on
> > the GTK3 library, which would have to duplicate that same depext
> > information. Granted, at the moment n = 1, but that's not really the
> > point.
> 
> Ah, indeed sorry I was not clear; indeed what I was thinking is about a
> model where the os-dependent information is centralized, but not by using
> a package, but a proper database of mappings / recipes.
> 
> So indeed maybe the core question is whether using "dummy" package for
> capturing this is the best abstraction.

Please let's not have another file format in opam :-/

> > Even if you carve the OS-specific package names off somewhere else,
> > "gtk3 >= 3.18" is not guaranteed to be how you'd express that on all
> > platforms, so that notion also probably needs to be centralised too
> > (one word: backports).
> 
> Indeed that's a problem; I would say that OPAM could talk about upstream
> version, but in some cases that may not be enough. But this is something
> the current model cannot do very accurately either, right?
>
> [Like if for example two packages A, B depend on gtk where A needs GTK >=
>  3.18-4 and B needs 3.20-2 where -x is the Debian version]

The current model can, inasmuch as you can create a dummy package whose purpose is to express what ">= 3.18" actually means for each individual packager. You can imagine that if you were talking about the Linux kernel, you may well have > 4.xx.yy for a stock kernel but a special case of > 3.10.x for RHEL, because the thing you want is backported (obviously a slightly banal example, because you'd never determine a kernel feature by version number, but hopefully it serves the point - there are other libraries where you might).

The current model can deal with packages A and B neatly, yes - what's not neat is that two separate packages get installed (conf-at-least-gtk-3-18 and conf-at-least-3-20). The build instructions for those two conf packages would include Debian-specific strings to test for the -x part. It's definitely not a perfect solution, but your proposal of versioned depexts I think simply moves the trade-off to be considerable complexity in the depext code from having a relatively small number of these dummy packages.

> > No - depexts are not part of the dependency tree for the solver,
> > they're metadata for a package which has already been selected by the
> > solver - that's why version constraints on them are harder to achieve,
> > because the packages have already been selected.
> 
> I meant that depexts are not, however the `conf- package is. So if we need
> 1 conf- package for each depext that doesn't seem to be a huge improvement
> right?

I'm sorry, I'm still not following the comparison here. Having 1 conf- package for each depext sounds entirely correct, in terms of the "database" of OS-specific package names for that depext.

> > Well, it's so much caring, as being able to! It's just not that the
> > conf- packages are not working well - they're doing exactly what
> > they're supposed to, they just can't do what you'd like them
> > additionally to do.
> 
> Sure, I was being concerned for user experience with `conf-gtk` where the
> package can be installed but the bounds are not the right ones.

Indeed - but the user experience is entirely correct to say "we can't install conf-gtk3 because you don't have the system libraries for it". It would then be correct to say "we can't install conf-at-least-gtk-3-18 because you have GTK3 < 3.18".

Not likely for gtk3, but imagine you were installing lablgtk3, marialablgtk3, librelablgtk3 and lablgtk3Org all of which, despite disagreeing with Jacques on how lablgtk3 should run as a project, all definitely agree that they depend on the underlying GTK3 binaries - the conf-gtk3 package gives a much better user experience if the GTK3 package is < 3.18 because it's the single failure, as opposed to all of them failing individually.

The conf-at-least-gtk-3-18 package would be able to display a very clear opam error message explaining the problem as the only error which can occur is that. 

> >> If I understand correctly then, as of today I could provide 2 lablgtk
> >> opam packages, one depending on conf-gtk3, and one not depending on
> >> it, and the user would actually have the same experience in the case
> >> of an incorrect gtk version, right?
> >
> > No - unless you mean that the two lablgtk packages would have
> > different names? One of them must fundamentally have a higher version
> > number than the other, and the one which depends on conf-gtk3 is
> > always going to attempt to install it - opam won't magically fall back
> > to the other one.
> 
> Sorry for the bad explanation. I meant to provide them "in parallel", like
> I could package lablgtk in this way or in that other way. Both of them
> would fail in the same way.

So provide the two packages in separate opam repositories? Yeouch. The user experience for the -conf version is capable of being slightly clearer, inasmuch as on a build error you can be reasonably sure that the error is the lack of GTK3, whereas a build error in lablgtk3 could be other things - opam's own error messages (in post-messages) are much clearer to consume than trying to read the build output, which is all you'd have in the other case.

> > Indeed - although IIRC it doesn't affect any other conf- packages, at
> > least yet. So can we conclude that having two conf- packages for now
> > is superior to leaving all that information permanently embedded just
> > in lablgtk3?
> 
> I am still not sure the release workflow is superior: we'd have to
> introduce 8 additional conf- packages, and we'd have to maintain the OS-
> dependent info in the repos anyways.

If there are 8 distinct depexts, then there should be 8 distinct conf- packages - I'm sorry if your library is complicated :o)

But look on the other side - these conf packages are only normally updated to include package names missing for other distributions - in other words, other contributors quietly improving them. It seems to be me that you're anticipating a maintenance burden which won't exist here, and doesn't exist for the conf- packages already in opam-repository.

> > Nothing prevents the maintainer of lablgtk3 also being the maintainer
> > of conf-gtk3 and conf-at-least-gtk3-18 (or whatever). If one chooses
> > just to maintain lablgtk3 and depend on conf-gtk3 then the
> > installability of that is the concern of opam-repository maintainers -
> > that's what we have CI for. Someone else who proposes a change to
> > conf-gtk3 which breaks lablgtk3 would be unable to get their PR merged
> > without in some way fixing lablgtk3. You seem happy that the ocamlfind
> > package is maintained by someone else. I mention it because the opam
> > package for ocamlfind is not (and I don't think ever has) been
> > maintained by ocamlfind's author...
> 
> I am trying to move all the OCaml software I work on to Dune + dune-
> release, thus in the future indeed packages will be maintained in-tree [by
> however takes care of the build system]

This is almost entirely separate - at present, Dune doesn't care about conf- packages, and you don't need to specify them. Dune also has no knowledge of depext, so even in a multi-project tree you're still responsible for ensuring that your system libraries are present, not Dune. The work going on in Dune to be able to generate opam files automatically is already aware of the need to support them.


David

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list
Forum: https://discuss.ocaml.org/
Bug reports: http://caml.inria.fr/bin/caml-bugs

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, back to index

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-06  6:33 [Caml-list] LablGtk3 beta1 Jacques Garrigue
2018-12-06 10:05 ` Louis Gesbert
2018-12-06 10:35 ` Gabriel Scherer
2018-12-07 10:04 ` Emilio Jesús Gallego Arias
2018-12-07 10:25   ` Gabriel Scherer
2018-12-07 18:34     ` Emilio Jesús Gallego Arias
2018-12-11  3:09       ` Francois Berenger
2018-12-11 11:34         ` Louis Gesbert
2018-12-14 11:41           ` Emilio Jesús Gallego Arias
2018-12-14 11:38         ` Emilio Jesús Gallego Arias
2018-12-16  8:12           ` Jacques Garrigue
2018-12-17 12:11             ` Emilio Jesús Gallego Arias
2018-12-18 14:33               ` David Allsopp
2018-12-19  1:20                 ` Emilio Jesús Gallego Arias
2018-12-19 10:15                   ` David Allsopp
2018-12-19 11:13                     ` Emilio Jesús Gallego Arias
2018-12-19 11:50                       ` David Allsopp
2018-12-19 16:41                         ` Emilio Jesús Gallego Arias
2018-12-20 11:33                           ` David Allsopp

caml-list - the Caml user's mailing list

Archives are clonable:
	git clone --mirror http://inbox.vuxu.org/caml-list
	git clone --mirror https://inbox.ocaml.org/caml-list

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.caml-list


AGPL code for this site: git clone https://public-inbox.org/ public-inbox