Re: Specify runtime dependencies with propagated-inputs or wrapper scripts

[Maxime Devos <maximedevos@telenet.be>]

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

On Fri, 2021-03-26 at 20:36 +0100, Léo Le Bouter wrote:
> Hello!
> 
> I often meet problems where some packages don't work out of the box
> because they have some runtime dependencies like themes or third party
> programs.
> 
> I solved these problems on occasion by making commits such as this: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=00c1793ce8e2210e48b18422ea3e76da10541874
> - which adds a wrapper script to "bin/chromium" and includes xdg-utils
> in PATH variable.
> 
> It works but it's tedious to do for each and every binary in every
> single package.
> 
> I see we also have a propagated-inputs field, which looks nice but for
> some reason people advice against using it. For what reasons?

One reason is incompatibility.
Try "guix environment --ad-hoc pidgin eom", it will fail.
(At least, it used to, due to both gtk+@2 and gtk+@3 being in a
single profile, or perhaps I got the package names wrong.)

Another reason is that you lose ‘scoping’ (not sure how to name this).
Consider each project to be like a Scheme module (M).  (M) can export
variables like:

<start snip>
(define-module (kitties))
(define-public binaries
  `(("stuff" ,do-stuff)
    ("surf" ,search-kitties)))
(define do-stuff ...)
(define search-kitties ...)

(define-public documentation
  `(("stuff" "TODO")
    ("surf" "In the beginning, there were kitties")))

[some library for adopting kittens]
<end snip>

Assume there is a module (puppies) as well, that also
has a "surf" binary.  Now consider an adoption centre application
(animal-adopt), that uses the "surf" binaries from both (kitties)
and (puppies) for finding kitties and puppies.  In Scheme-land,
this works just fine, without ambiguity:

  (call-binary "surf" #:module '(kitties))
  (call-binary "surf" #:module '(puppies))

However, this won't work if all binaries were in a single, global
hash table, instead of being defined per-module (or package in Guix-speak).

How could "animal-adopt" use both "kitties" and "puppies" if it were
to add "kitties" and "puppies" to propagated-inputs?  Also, if
"animal-adopt" only has "kitties" as propagated-input, how could
a user install both "animal-adopt" and "a-browser-simply-named-surf" in their
profile?

> it is not as tedious as wrappers and I would really like to be able to specify
> runtime dependencies of packages using it without problems.
> I think we must find a solution to this runtime dependencies problem
> that is better than wrapper scripts because they are very tedious to
> create for every single binary in every single package.

This seems a difficult problem.

> Another recent example being that the caja package depends on dconf to
> change it's settings, which is not installed by default when users use
> window managers like sway.
> 
> Let's find a convenient solution here that would allow us to put an end
> to these problems that affect many new users and remains obscure for
> them that they would need to add additional packages in their
> configuration (and which).

In order to discover these kind of issues earlier, it would be interesting
to create a "ambient-trouble" package, that has binaries named after
the common culprits "xdg-config", "which", "cat" (for shell scripts actually
requiring "coreutils"), maybe some others, to be used like this:

$ guix environment --ad-hoc software-to-test ambient-trouble
$ AMBIENT_TROUBLE_LOG=$HOME/ambient-trouble.log software-to-test

The fake "xdg-config", "which", "cat" ... would then write a line
to $AMBIENT_TROUBLE_LOG and return 1 (failure).  In the package guidelines
we could recommend testing with "ambient-trouble".  To find out current
violations, ‘someone’ could install "ambient-trouble" in their profile
and see what breaks.

Now I think of it, it should be sufficient to test with
"guix environment --pure", but it clears out too many variables
(e.g. DISPLAY is not unset, but XAUTHORITY is --- see
%precious-variables in guix/scripts/environment.scm).

Is there any reason why XAUTHORITY is unset but DISPLAY isn't?

After all, "guix environment --pure" is not that pure that it
removes process persona, removes the reference to the root & current
working directory from the process ... I don't see why keeping the
reference to the display server accessible would be any different from
keeping standard input/output/error open.

It's all I/O, the only (conceptual) difference is in representation
(text/bytes or pixels).

Greetings,
Maxime.

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