Hi, Am Mittwoch, den 18.08.2021, 11:28 +0200 schrieb Maxime Devos: > Leo Prikler schreef op wo 18-08-2021 om 10:03 [+0200]: > > Hi John, > > > > a lot of packages would do much better if they exported > > XDG_CONFIG_DIRS. However, there is currently no way of doing so > > other > > than copypasting the same snippet over and over and over and > > over. A > > workaround -- if you need this in an environment -- is to also > > include > > a package, that already has a search path on XDG_CONFIG_DIRS, like > > glib > > (I think glib:bin works too). > > > > I recently tried exporting XDG_CONFIG_DIRS as a variable from one > > module, so that it can be referenced in others, but that led to a > > weird > > recursive errors. It would be nice to find a good way of doing > > that, > > though. > > What do you think of defining the <search-path-specification> > $XDG_CONFIG_DIR in (guix search-paths) itself, next to $PATH? That > seems > unlikely to lead to recursive errors. > > Alternatively, I would guess that making 'search-paths' and > 'native-search-paths' a ‘thunked’ field would resolve the errors, > at cost of making <package> objects use a bit more memory. Both sound like interesting proposals. Obviously, adding $XDG_CONFIG_DIRS to (guix search-paths) would work in the short term, but I think defining all interesting environment variables there is probably not the best solution for the future. There's a few variables that are used widely FSVO widely, but using them also implies having some package as input, e.g. the cURL-related ones. XDG_CONFIG_DIRS technically also falls in there, because you will have either xorg or xdisorg imported. Therefore, I think I'd prefer a solution where variables can be exported (and re-exported) from any module in the (gnu packages) subtree.
Regards
