* Re: Specify runtime dependencies with propagated-inputs or wrapper scripts
2021-03-26 19:36 Specify runtime dependencies with propagated-inputs or wrapper scripts Léo Le Bouter
@ 2021-03-26 20:55 ` Leo Prikler
2021-03-26 21:56 ` Maxime Devos
1 sibling, 0 replies; 3+ messages in thread
From: Leo Prikler @ 2021-03-26 20:55 UTC (permalink / raw)
To: Léo Le Bouter, guix-devel
Hello,
Am Freitag, den 26.03.2021, 20:36 +0100 schrieb Léo Le Bouter:
> 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.
Including xdg-utils in PATH works, but the preferred solution in Guix
is to use absolute paths where possible.
> It works but it's tedious to do for each and every binary in every
> single package.
You could argue the same about bootstrapping :P
> I see we also have a propagated-inputs field, which looks nice but
> for
> some reason people advice against using it. For what reasons? 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.
Using propagated-inputs is a double-edged sword. On the surface, it
seems to solve all your problems, but underneath it introduced back all
the dependency shenanigans, that Guix seeks to avoid. In particular,
you can't upgrade just one of N libraries, that all (indirectly)
propagate the same input.
> 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.
Le me presenting an even more tedious solution :)
> 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.
Shouldn't there already be a library for this? *sigh*
> 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).
We could probably do our best to search for variants of exec in all
kinds of programming languages automatically and then do our
substitute*s with (which "program"), but I personally believe
explicitly doing this is less surprising overall.
Regards,
Leo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Specify runtime dependencies with propagated-inputs or wrapper scripts
2021-03-26 19:36 Specify runtime dependencies with propagated-inputs or wrapper scripts Léo Le Bouter
2021-03-26 20:55 ` Leo Prikler
@ 2021-03-26 21:56 ` Maxime Devos
1 sibling, 0 replies; 3+ messages in thread
From: Maxime Devos @ 2021-03-26 21:56 UTC (permalink / raw)
To: Léo Le Bouter, guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread