Hi Leo, ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler wrote: [...] > > > > > > > > > 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). > > Haha, my bad, yeah glib only provides XDG_DATA_DIRS. In that case I'm > > not sure which one would be the canonical workaround package. > Okay, just checking! I didn't see any workaround package, very few references to XDG_CONFIG_DIRS in our packages. > > > > > 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'm not sure about that myself but the answer is probably no. > > > 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 think the likelier explanation is that XDG_CONFIG_DIRS is possibly > > underused when compared to XDG_DATA_DIRS. Most packages store their > > configuration -- if any -- in /etc/foo rather than /etc/xdg/foo. I'm > > pretty certain that using /etc/xdg rather than /etc was an error on > > XDG's part as XDG_CONFIG_HOME, which defaults to ~/.config makes much > > more sense from an application writer's POV. > It does seem less universal. On a non-Guix system I see a handful of programs that keep default configurations there, things like ICC profiles, and of course autostart .desktop files. > > 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.) > > You are indeed right, multiple profiles are very badly supported by > > Guix. Needing to jump through the hoops described in the cookbook in > > the first place is in my eyes a clear enough indicator to support my > > point. > And I think that is a shame, as profiles and manifests are such a great feature of Guix. The ability to compartmentalize package groups is very nice just on the organizational level, but does seem less than fully incorporated at this point. It is a shift from the non-Guix distro experience. > Back in December of 2019, I wrote a proposal that would make it > > possible to add user profiles next to the default profile [1]. It had > > a few problems mostly related to underspecification and in the end went > > nowhere. Earlier this year, around Guix Days, I thought I should > > perhaps revive it, but for personal reasons didn't, instead > > procrastinating. The only thing I now remember from back then was that > > there was a certain push from fellow proponents to just use > > $XDG_DATA_HOME/guix as this directory, but I'm still concerned whether > > that is the correct approach (particularly since /etc/profile might not > > know about the actual value of XDG_DATA_HOME in time). > .config/guix is hardcoded in a few places already isn't it? (or is that just for root? took just a quick look) Personally, I prefer everything in .config to keep the home folder cleaner, but we all know there's a strong mix of things like $HOME/.something and $HOME/.config/something. This is just a detail, but could always default to something that matches XDG even if XDG variables aren't available. Or maybe better to break away anyway since it is something a bit different. Details. > I think that in order to truly make profiles splits work, we would > > either have to make use of Guix at the lowest level, so as to merge > > Emacs in one profile with a bunch of emacs-foo packages in another or > > make search paths first-class citizens of profiles to allow for > > amendments on top of what is already given by packages. > > WDYT? > > [1] > > https://yhetil.org/guix-devel/eabe0cccdb377b1c573df88715d6aebf7bf7f80c.ca...@student.tugraz.at/ Yes, that seems like some options. Personally, I'm a fan of promoting (multiple) profiles to more fully first-class citizens in Guix, as that would fit well. E.g. having a canonical profile directory, or otherwise making it more baked into the system so you don't need to manually add scripts to loop over profiles. I suppose that still leaves the question of search paths. I don't think I know enough of the internals to have a helpful input here so far. Handling multiple profiles together would help pull in some search-paths and maybe alleviate #48538 (dbus)? Would then /etc be constructed from all the profiles together (by passing this XDG_CONFIG_DIRS issue)? If it is still /etc in each profile relying on env to find things, then at least in this case XDG_CONFG_DIRS still has to appear somewhere. Search paths in profiles could be good, conceptually works for how profiles are used, to me. John
