GNOME in Guix

[Leo Prikler]

Hi Danny,

Am Montag, den 02.11.2020, 11:17 +0100 schrieb Danny Milosavljevic:
> Hi,
> 
> On Mon, 02 Nov 2020 08:44:29 +0100
> Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> 
> > Danny Milosavljevic <dannym@scratchpost.org> writes:
> > > Not much more works yet because I've hit this (design) bug in
> Guix and/or 
> > > GNOME:
> > >
> > > * https://github.com/spk121/guile-gi/issues/96  
> > 
> > Have you tried g-golf?  The Nomad browser uses it, it may not
> suffer
> > from the aforementioned issue.
> > Thoughts on that?
> 
> It really depends on what you mean.  If it also uses gobject-
> introspection, it
> will have the same problem.
As much as I rant about nomad in IRC now and then, it is still a rather
sophisticated program, and as a user I have not yet encountered any
problem similar in effect to what is described here.  
The bugs I do encounter whenever I try it out for my own amusement are
much rather due to g-golf and emacsy being in rather early stages of
development and therefore not feature-complete.

I am not sure, whether the Nomad devs have encountered a problem
similar to Guile-GI#96 (I myself am not one), but the Guile-GI devs
speculate, that the problem is somewhat specific to their
implementation.
They also mention, that you should still be able to prototype your
application by using "--no-grafts" for the development environment.  Do
you still encounter Guile-GI#96 after packaging?  If so, you might want
to explain your situation upstream, so that they can better help you.

> Even gobject-introspection links to glib internally, then registers a
> class in
> that, THEN opens (potentially another) glib at runtime using dlopen
> in the same
> address same.
> I'm pretty sure that GNOME is not designed for that.  If you then use
> the
> dlopened glib to use the first-mentioned class, good luck with that.
> 
> The only reason it didn't fall onto the head of users of other
> distributions
> is because those don't support internal dependencies of packages at
> all--so
> you always have to update all in lockstep.  So the following can only
> happen
> in Guix:
> 
> If a library A has an input Q, and library B has the same input Q,
> and you
> use A and B in your program, and then you (guix-) update just B to
> use Q'
> (for example a newer version of Q) and recompile your program, then
> you have
> both Q and Q' in your process address space!
> 
> Q is an internal dependency of A, and by coincidence it's an internal
> dependency of B, too. Just because the internal dependency of B
> changed
> shouldn't change the internal depenency of A--that's what "internal"
> means.
Sure, but that's only if either of them ends up using a different
version.  That should not be the case for Guix' GNOME stack apart from
some bootstrap shenanigans, that don't really matter at the point of
application packages.

In order to make use of any GI in Guix, you need
- the GI bindings (one of python-gobject, g-golf, guile-gi, gjs, etc.),
- *and* the packages of the libraries themselves
as inputs to your package.  So the resulting graph for your package
will always be complete and should only contain one relevant package
per library.

And yes, you can totally do that on other distros as well.  (One way to
do so would be to use Guix on them ;D)  It's just that users typically
shy away from installing conflicting versions of the same package,
whereas Guix will happily allow them to coexist and go out of its way
to deal with potential issues arising from that.

> I think that the gobject type registry does not consider that it can
> happen
> to have to classes with the same class name, registered in respective
> internal dependencies.  The objects of the internal dependency
> shouldn't
> be available to the outside program in the first place.

Yes it does, or at least you can check, whether a type of that name is
already registered and bail.  You could even do so in Guile-GI as you
are instantiating the types, but I doubt upstream devs want to bail
when they encounter a reserved type.

> That means actually we should propagate a lot of GNOME inputs, which
> means
> in practice what a regular user has in his profile will be very much
> like
> in other distributions, and internal dependencies will become a weird
> corner
> feature nobody uses.

No, it does not.  It perhaps means, that we might want to take care of
GI_TYPELIB_PATH in glib-or-gtk-build-system.  It at least would make
sense to add logic dealing with gobject-introspection to glib-or-gtk-
wrap, which could then be reused in other build systems as well.

Packages, be they GNOME or not, should be dynamically linked, so that
Guix can correctly graft them.  Assuming correct grafting, the library
loaded from GI_TYPELIB_PATH should be the same as the library loaded
internally with the build setup I discussed earlier. 

> Does anyone know how to make dlopen fail on duplicate global
> variables?
No, but I don't think that is too relevant here.  See my earlier point
on how it *is* possible to handle this with the methods GLib provides.

Am Donnerstag, den 29.10.2020, 20:34 +0100 schrieb Danny Milosavljevic:
> Or I could just use Gtk in C and use popen("guix ...").
You're probably joking, but you should know, that I had moderate
success passing around just data from Guile to Gtk while not using g-
golf or guile-gi.  You could either do all your conversions in C like I
did back then or declare your own data models as C structs and then
fill them from guile using e.g. guile-bytestructures.
Obviously, it would be nicer if one could program the GUI itself in
Guile, but you are free to make the choices you feel are fitting.

A slightly more elaborate approach would be to try and expose Guix over
DBUS (this would require guile bindings to dbus, that afaik don't exist
outside of projects that want to happily marry Guile and GNOME).  Once
that is written, you could again write your GUI in any language.  Using
DBUS would probably also enable you to get fine-grained control over
when to grant administrative privileges for `guix system`.

Regards, Leo