bug#22138: Should search paths of dependencies be honored automatically?

[Maxime Devos]

(first section)

> As of 0.9.0+, only the search paths of packages explicitly in the
> profile are shown by ‘--search-paths’ and similar.  This is a problem
> for libraries that have associated environment variables.
>
> For instance, if one installs an application linked against OpenSSL,
> they will not know about ‘SSL_CERT_DIR’ and ‘SSL_CERT_FILE’. Similarly
> for GStreamer and ‘GST_PLUGIN_PATH’, libc and ‘GUIX_LOCPATH’, and so on.
> [...]
> [... stuff about references-graph ...]

I want to note that it is possible to use a library in a program without
needing the environment variables.  E.g., web servers can use openssl,
but often only for listening so they don't need a certificate bundle.
A game using GStreamer for sounds knows in advance which plugins it will
need, so the package definition would be using 'wrap-program' or the like
to hardcode the set of plugins.

Many (almost all?) packages keep a reference to the "lib" output of "gcc",
but almost no packages need '{,CROSS_}C_INCLUDE_PATH', 
'{,CROSS_}CPLUS_INCLUDE_PATH' or
'{,CROSS_}LIBRARY_PATH'.

That said, adding these superfluos environment variables is probably
harmless in practice, but it kind of breaks some abstractions:

If I use a package as input that uses a search path and I fix the search path
using 'wrap-program' or the like, then I would expect things to be as if there
wasn't a search path in the first place, but IIUC the proposed patch looking
at references would break things.

Also, the patch seems to only affect profiles and not build environments,
creating another distance between them, which seems suboptimal.

For these reasons, I don't think search paths of dependencies should be 
honoured.
However, there are things to improve:

(second section)

I believe a better option would be to document search paths better in the manual
(there's almost nothing currently about search paths) and make search paths 
easier
to use.

E.g., we could move ‘generic’ search paths used by several packages (e.g.
INFOPATH, TERMINFO_DIRS, XDG_DATA_DIRS, GST_PLUGIN_PATH, SSL_CERT_DIR
and SSL_CERT_FILE --- why is SSL_CERT_DIR missing from icecat and guile
anyway?) (counter-example: MINETEST_MOD_PATH, because it is used by only
one package) into a common module next to each other, which some small comments

  [...]
  ;; FWIW I think I suggested something like this elsewhere, in the context
  ;; of module import loops.

  ;; for info readers (info-reader, emacs, ...)
  (define-public %info-path ...)
  ;; for programs interacting with terminal emulators,
  ;; e.g. almost anything using 'ncurses'
  (define-public %terminfo-dirs-path ...)
  ;; for packages using TLS, e.g. web browsers (icecat, ungoogled-chromium, 
...),
  ;; e-mail clients (evolution, icedove ...), most software 'openssl'
  ;;
  ;; Not all packages using TLS respect one of these two variables.
  ;;
  ;; (TODO check if these examples actually respect SSL_CERT_DIR/PATH)
  (define-public %x509-cert-dir-path ...)
  (define-public %x509-cert-file-path ...)
  [...]

and mention this module in the documentation of 'search-paths',
invite people to look at the source code of the module for examples
people maybe even documenting these search paths in the manual.
Maybe also insert a reminder about search paths in the 'reviewing' section?

I think this (keeping standard search paths together, with some explanation,
with some example packages using these search paths ...) would help 
discoverability
a lot, reducing the risk that a package is defined without appropriate search 
paths.

Such a common module would also reduce redunancy (a single definition of 
%foo-path
instead of sprinkling it among separate packages) and reduce the chance of 
module import
loops (maybe we can move the python search path there?), although the latter 
could
be solved with thunking (at some cost).

It's also possible to do both this (manual documentation, common search path 
module)
and the patch using the reference graph.

This ignores GUIX_LOCPATH, but that's used by almost anything, so it could be
special-cased I think?

Greetings,
Maxime.

signature.asc
Description: This is a digitally signed message part