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
