Sebastian Schott <s.schott@mailbox.org> writes:

> Hi Chris,
>
> you are right, some libraries I added in native-inputs of
> rapid-photo-downloader cause trouble, e.g., I got "ValueError:
> Namespace Notify not available", when I try to start the program. This
> is a bit confusing, because before committing, I successfully tested
> this, but maybe I manually installed these libraries and therefore had
> no "clean" testing environment.
>
> Now, I experimented a bit with native-inputs, inputs and
> propagated-inputs and managed to start the program, when I install it
> with the code at the end of this mail (./pre-inst-env guix install
> rapid-photo-downloader). When I just build the program and cd into the
> store folder to run it, I still got the "notify error" (./pre-inst-env
> guix build rapid-photo-downloader --> cd /gnu/store/.../bin -->
> ./rapid-photo-downloader). This makes sense, because without
> installing the program, also the propagated-inputs are not installed.
>
> What is the recommended way to test a program without interfering with
> the current user profile, but still considering propagated-inputs?

Probably using guix environment --ad-hoc, although to set up the right
search paths, you'll need to also include some other packages in the
environment.

Propagated inputs with search paths are great for things like plugins,
and programming language libraries, but for improved reliability and
compatibility, they should be avoided for applications like Rapid Photo
Downloader.

> You mentioned inputs are used for libraries required at runtime. Now I
> wonder, why I need to put libnotify, libgudev, usdisks and gexiv2 into
> the propagated-inputs to avoid errors like "ValueError: Namespace
> Notify not available"?

Probably because of a search path like GI_TYPELIB_PATH. I've taken an
earlier version of your patch, and tweaked it [1] so that I can start
the application directly from the store (running [2]).

1: https://git.cbaines.net/guix/commit/?h=series-2725-tweaked&id=85613884ac9c4122460923aaf1e28ef13aab49df
2: /gnu/store/6ssz223fy59cpz3582jd3xqva49m9w8n-rapid-photo-downloader-0.9.18/bin/rapid-photo-downloader

If you take a look at that file [2], you'll see it's a bash script,
which sets a number of environment variables. This comes from the
wrap-program call in the patch [1].

Now using wrap-program is not an ideal technique, but what I think this
approach does provide is that it reduces the chance of other things in
your profile breaking rapid-photo-downloader, and it also means that you
can install another application that also uses a common dependency, but
has a different version of it, or a patched version, without running in
to difficulties combining both packages in to one profile.

Does that make sense?

Thanks,

Chris