Hi Leo and Maxime, Thanks for discussing this. A few questions/clarifications (perhaps mostly because I'm still new here) below. I'm not familiar enough with the internals of guix search-paths, so my perspective is mostly from the end-user standpoint.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 18th, 2021 at 5:45 AM, Leo Prikler wrote: > 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'm slightly confused here: I only see XDG_DATA_DIRS in the glib package. I include glib to get that export actually (I have everything in profiles, nothing in the default user). Autostart files are in $XDG_CONFIG_DIRS/autostart. XDG_DATA_DIRS seems to come up the most and more needed it seems to me (based on what I have there in a desktop environment). > > > 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. > Is the case here that glib should have XDG_CONFIG_DIRS in it? Or does that only make sense in some other package that could then be included in a profile to get XDG_CONFIG_DIRS, similar to XDG_DATA_DIRS now? I didn't see many references to XDG_CONFIG_DIRS in our current packages, mostly in some Lisp compilers and a few other random places. Slightly surprised it is not in more, but maybe packages that would normally put something in /etc/xdg (default for XDG_CONFIG_DIRS) have been configured otherwise. I feel like my setup, from the cookbook, of having everything in profiles with the default user one being empty other than testing, has exposed a few related issues. What we are discussing might also have relevance to dbus files (see #48538), and perhaps to an older issue about paths and /etc/profile (#20255). (Not to bring up an old issue, but it was one that came up when searching for related issues in the past, which I skimmed.) John
