Clarification regd. native-search-paths and search-paths

Clarification regd. native-search-paths and search-paths

[Suhail Singh]

Hello Guix,

Per the manual:

#+caption: [[info:guix#Search Paths][guix#Search Paths]]
#+begin_quote
  What this ‘native-search-paths’ field says is that, when the ‘python’
  package is used, the ‘GUIX_PYTHONPATH’ environment variable must be
  defined to include all the ‘lib/python/3.9/site-packages’
  sub-directories encountered in its environment.  (The ‘native-’ bit
  means that, if we are in a cross-compilation environment, only native
  inputs may be added to the search path; *note ‘search-paths’: package
  Reference.)
#+end_quote

Does "used" above refer to runtime usage?

If so, in that example, why is native-search-paths used instead of
search-paths?  I would think that in order to have appropriate runtime
behaviour while supporting cross-compilation, we would want to use
search-paths instead.  And yet, it seems, the recommendation seems to be
to favour native-search-paths in general:

#+caption: [[info:guix#package Reference][guix#package Reference]]
#+begin_quote
  As for inputs, the distinction between ‘native-search-paths’
  and ‘search-paths’ only matters when cross-compiling.  In a
  cross-compilation context, ‘native-search-paths’ applies
  exclusively to native inputs whereas ‘search-paths’ applies
  only to host inputs.

  Packages such as cross-compilers care about target inputs—for
  instance, our (modified) GCC cross-compiler has
  ‘CROSS_C_INCLUDE_PATH’ in ‘search-paths’, which allows it to
  pick ‘.h’ files for the target system and _not_ those of
  native inputs.  For the majority of packages though, only
  ‘native-search-paths’ makes sense.
#+end_quote

How does one determine which of native-search-paths or search-paths is
appropriate in a given context?

-- 
Suhail

Re: Clarification regd. native-search-paths and search-paths

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Suhail,

On Sat, Oct 05 2024, Suhail Singh wrote:

> Does "used" above refer to runtime usage?

It refers to any use of the "python" package.

The native specifier means that the inputs have the same architecture
that Python is building something else on, rather than the architecture
it building that something else for.

Inputs intended for the target architecture are runtime inputs.

> How does one determine which of native-search-paths or search-paths is
> appropriate in a given context?

I'm not sure whether it makes a difference for interpreters.  Perhaps
the distinction arises because some Python modules are compiled and
machine-dependent.

Kind regards
Felix

Re: Clarification regd. native-search-paths and search-paths

[Suhail Singh]

Felix Lechner <felix.lechner@lease-up.com> writes:

>> Does "used" above refer to runtime usage?
>
> It refers to any use of the "python" package.

Since I am trying to understand what constitutes "use", could you please
give examples?  For instance does use here mean being an "input" to a
package?  Something more/less/else?

> The native specifier means that the inputs have the same architecture
> that Python is building something else on, rather than the architecture
> it building that something else for.
>
> Inputs intended for the target architecture are runtime inputs.

Given above, I would expect adding a variable to search-paths or
native-search-paths to be functionally equivalent when not cross
compiling.  Do you agree with this, or am I mistaken in my conclusion?

>> How does one determine which of native-search-paths or search-paths is
>> appropriate in a given context?
>
> I'm not sure whether it makes a difference for interpreters.  Perhaps
> the distinction arises because some Python modules are compiled and
> machine-dependent.

At least for certain variables such as $SSL_CERT_DIR and $SSL_CERT_FILE
they only have the desired effect when added to native-search-paths.
When they were added to search-paths, I observed errors when accessing
HTTPS resources (in a pure container with nss-certs included in the
profile).  When they were added to native-search-paths instead, the
errors went away.

-- 
Suhail

Re: Clarification regd. native-search-paths and search-paths

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Suhail,

On Sun, Oct 06 2024, Suhail Singh wrote:

> does use here mean being an "input" to a package?

Yes, precisely.  Or being used in a profile.

> I would expect ... search-paths or native-search-paths to be ...
> equivalent when not cross compiling.  Do you agree?

Not sure.  I packages may still distinguish whether their inputs are
"native" or not.

> At least for certain variables such as $SSL_CERT_DIR and $SSL_CERT_FILE
> they only have the desired effect when added to native-search-paths.

Did you also move the input that provides the TLS certificates away from
native when you tried?

Kind regards
Felix

P.S.  I'm a Guix learner who likes to help.  Please don't trust anything
I write.

Re: Clarification regd. native-search-paths and search-paths

[Suhail Singh]

Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

>> does use here mean being an "input" to a package?
>
> Yes, precisely.  Or being used in a profile.

I see.  Thank you.

>> At least for certain variables such as $SSL_CERT_DIR and $SSL_CERT_FILE
>> they only have the desired effect when added to native-search-paths.
>
> Did you also move the input that provides the TLS certificates away from
> native when you tried?

Ah, I think not.  I think I see now what Rutherther (on IRC) meant when
they said that guix shell adds to native-inputs.

The input that provided the TLS certificates in my case was nss-certs.
I provided it by adding it to a profile which I then loaded via guix
shell.  It seems this adds it to "native"?

> P.S.  I'm a Guix learner who likes to help.  Please don't trust anything
> I write.

Heh, ditto.  While the disclaimer wasn't strictly necessary, I
appreciate your clarification.

-- 
Suhail