unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: Peter Polidoro <peter@polidoro.io>
Cc: help-guix@gnu.org
Subject: Re: Finding Dependencies at Run Time
Date: Wed, 13 Jul 2022 23:02:11 +0200	[thread overview]
Message-ID: <AC9B4F6C-DA90-4D2A-B4B7-2DD6245A4D3A@lepiller.eu> (raw)
In-Reply-To: <867d4ghltf.fsf@polidoro.io>

My explanation must not have been clear. You can read more on search-paths at https://guix.gnu.org/manual/devel/en/html_node/Search-Paths.html#Search-Paths

Basically, it's a declaration on packages that specify which path-like environment variables they honor.

When building an environment/profile, guix will look at all the variable declarations of packages of that environment and create the corresponding variables.

So when building a package, guix creates an environment with all the dependencies (inputs) of the package, and the corresponding environment variables.

Similarly, when you install say python (that brings in its search-path definition) and python-numpy (that provides a python library), guix will know to set GUIX_PYTHONPATH properly for using numpy with python. Since numpy propagates its dependencies, they are also part of the environment and that's how numpy can find them.

Remember the difference between inputs and propagated inputs: they're the same, but when you create a profile, inputs are not part of the profile (so they need a direct store reference, such as RPATH or a wrapper), whereas propagated inputs are part of the profile, so an environment variable allows to find them.

Le 13 juillet 2022 20:51:18 GMT+02:00, Peter Polidoro <peter@polidoro.io> a écrit :
>Your explanations are very helpful, thank you, and your links made me realize that devel version of the manual has lots of information that I could not find in the stable version of the manual.
>
>> During the build, search-paths and native-search-paths are used to set up environment variables. If you use --keep-failed and interrupt a
>> build you'l find them in /tmp/guix-build-…/environment-variables.
>
>So search-paths and native-search-paths are set before the build and unset after the build so they are unavailable during run-time? Or are native-search-paths only available at build-time and search-paths available at both build-time and run-time?
>
>Are the search-paths and native-search-paths absolute path values found by automatically searching the directories in all of the inputs or native inputs, looking for files or directories that match a pattern? So they are a way to map relative paths into absolute paths to the dependency packages?
>
>> For others, the required search paths can be embedded in a wrapper, which defines environment variables before calling the actual program.
>
>So if a package needs run-time environment variables, then a package should use wrap-program to attach them to a command? These are not found automatically by searching the inputs, they must be manually defined using explicit input paths?
>
>> For propagation, dependencies are found in the environment. It's less "pure" than the other ways, so we try to avoid resorting to that.
>> Unfortunately some programming languages don't really leave us a choice (like python…).
>
>So python packages are not using an environment variable, such as PYTHONPATH, to find dependencies? How are they placed together into an environment so they can find each other?

  reply	other threads:[~2022-07-13 21:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 14:56 Finding Dependencies at Run Time Peter Polidoro
2022-07-13 16:03 ` Julien Lepiller
2022-07-13 17:47   ` Peter Polidoro
2022-07-13 18:39     ` Julien Lepiller
2022-07-13 18:51       ` Peter Polidoro
2022-07-13 21:02         ` Julien Lepiller [this message]
2022-07-14 17:47           ` Peter Polidoro
2022-07-16 21:53             ` Thiago Jung Bauermann
2022-07-14  8:25         ` Ricardo Wurmus
2022-07-14  8:48           ` Philip McGrath
2022-07-14 11:28             ` Ricardo Wurmus
2022-07-14 13:27               ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AC9B4F6C-DA90-4D2A-B4B7-2DD6245A4D3A@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=help-guix@gnu.org \
    --cc=peter@polidoro.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).