Hi Leo, ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, August 18th, 2021 at 12:35 PM, Leo Prikler wrote: > Hi John, > > For the record, you should try to cite in a way, that lines don't get > broken. I have no idea why this is happening > I just noticed that too, sorry. Seems protonmail likes to wrap at a shorter length and introduces these blank lines. Guess it is about time I get this account into mu4e. > Am Mittwoch, den 18.08.2021, 16:06 +0000 schrieb John Kehayias: > > > Hi Leo, > > > > On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler wrote: > > > > [...] > > > > .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. > > $(HOME)/.config is particularly hard-coded in the current /etc/profile, > which is why I dub it "fake XDG conformance". I personally disagree > with the use for $(HOME)/.config for software packages. > Well, it is all a bit of a mess. Off topic, but I try to use literate org files and stow to wrangle everything. > > [...] > > > > 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. > > For context, `guix package --search-paths' would implement the merged > approach IIUC, but then you would have to invoke guix from > /etc/profile, which reportedly is not every person's tea. You could > still manually source $GUIX_PROFILE/etc/profile, but would then get an > incomplete view depending on what your profiles look like. > That was the discussion in #20255 that was never resolved. In this case, I don't think any combination of `guix package --search-paths` will update XDG_CONFIG_DIRS since it is not in the native-search-paths of any of my included packages, as far as I can tell. I do see it included in qtbase, but I'd rather avoid pulling that in unless I actually have qt packages (which I probably will at some point). Just checking, and installing qtbase would indeed add XDG_CONFIG_DIRS to the /etc/profile as expected. Is there a reason qtbase has it but nothing on the glib/gtk/xorg side? > As for the XDG_CONFIG_DIRS, I don't think your scenario is the only > possible one, but with things being as they are currently, it is among > the likeliest outcomes. Another approach would be to define "precious" > search paths, which would be considered even if not explicitly > mentioned by any package/profile. (I think this somewhat overlaps > with/complements search paths as a first-class manifest citizen). I'm > just throwing out ideas here, so you shouldn't necessarily take any of > them as the solution to all our problems or something that can be > easily implemented given the status quo, but if you want, you can take > some inspiration from them or try out your own (thought) experiments. > I understand, this is a longer-term direction to discuss (I can certainly work around this issue in many ways). I think the related dbus issue #48538 is more noticeable, but all point towards better sorting out how we treat profiles and search-paths. My process as a new Guix user is to get everything working as I like it, and then try to reduce the edge case workarounds I've had to put in (a related one is #44997, for packages that may put things in /etc/profile.d). I think it would be good to get some overall input and direction for what people would like as the next steps in how we manage profiles (and search-paths). Thanks for the discussion so far, hopefully we can get some broad design choices and end goals in mind to then work out details. John
