Canop
Support XDG_CONFIG_DIRS for systemwide configs/defaults
Hi, thanks for broot :) it's great.
broot supports XDG_CONFIG_HOME, e.g if I export XDG_CONFIG_HOME=~/.foo, broot will look for a config under ~/.foo/broot. However it does not appear to support XDG_CONFIG_DIRS e.g /etc/xdg which is commonly used for defaults or to set system-wide configurations for all users (while allowing XDG_CONFIG_HOME configs to override them).
To be clear, the XDG spec essentially says that HOME has highest priority, but if not exists it should fall back to DIRS which is itself a list of directories in order of priority, that defaults to /etc/xdg.
If broot were to explicitly support this it would become an extra conditional block after the first one here: https://github.com/Canop/broot/blob/424023b4b084e071ecf67fc719db56ce40a01345/src/conf/mod.rs#L38 But I can see that the "directories" crate is already handling XDG stuff, so i'm unsure if this is a deficiency in that library, or if there is supposed to be a separate method for obtaining the DIRS paths.
[edit]
On closer inspection of "directories" it doesn't appear to fully support the XDG spec, and is instead limited to only XDG_CONFIG_HOME.
There is however an "xdg" crate which resolves config paths appropriately through both environment variables and more: https://docs.rs/xdg/2.4.0/xdg/struct.BaseDirectories.html However this obviously doesn't do the Windows parts.
Would you be willing to include this extra dependency for to fully support XDG?
Hi @ThomasBrierley
I'd rather not have this behavior fixed in Broot. IMO the change should be done in the directories crate itself (with a fork if it's not maintained) or by the choice or creation of another crate. I know it's not really a comfortable job because people have strong and different ideas about the standards and it is necessary to support Macs and Windows. A good job there would probably imply writing a complete table with all the paths for all the platforms, with the references to the norms.
I don't have time right now for diving into it. Do you want to try continue investigating in search of the perfect crate or building it ?
I agree, it's not broots concern.
I was actually thinking the "xdg" crate (which appears to have comprehensive XDG support) could be used alongside the existing "directories" crate, perhaps by falling back to it for windows/mac specific directories when an XDG one cannot be resolved.
I'll try to explore this (and other crates) myself but i am a complete newbie to rust, so if anyone feels like picking this up, go ahead.
As I said, I didn't dive and can't immediately. But if your investigation is correct, the right solution would be either to fix the directories crate (maybe create an issue in this project and link to here?) or to create a new crate calling both directories and xdg.
Why not sidestep this entire issue and just have a dedicated BROOT_CONFIG_DIR variable that defaults to XDG_CONFIG_HOME if undefined?
Supporting a BROOT_CONFIG_DIR would be easy and costless but most people would probably have broot configured before they learn about this variable.
Any other opinion on that ?
most people would probably have broot configured before they learn about this variable.
That is true. But then again, it is quite common for people to get something basic running with default settings, then only incrementally learn about and customize it as they become more proficient. It would only be a matter of running mv $XDG_CONFIG_HOME/broot $BROOT_CONFIG_DIR anyway.
Alternatively, you could implement a --config-dir option with a path to a custom location. ipython supports this, for instance. Though honestly, that would probably be more involved to implement, and I'm not sure it would bring any additional functionality/usability over an environment variable.
Supporting a
BROOT_CONFIG_DIRwould be easy and costless but most people would probably have broot configured before they learn about this variable.Any other opinion on that ?
@Canop Any decision on this yet?
Do you need it precompiled to test it ?
Yes please, if it's not too much trouble. I'm not too rusty :)
Sorry for the delay. I suddenly became super busy last month.
Anyway, I tried the builds you shared, but can't seem to find one that works with my system:
❯ for b in $(fd broot build -tx); do $b; done
zsh: exec format error: build/aarch64-unknown-linux-gnu/broot
zsh: exec format error: build/aarch64-unknown-linux-musl/broot
zsh: exec format error: build/armv7-unknown-linux-gnueabihf/broot
zsh: exec format error: build/armv7-unknown-linux-musleabi/broot
zsh: exec format error: build/x86_64-linux/broot
zsh: exec format error: build/x86_64-pc-windows-gnu/broot.exe
zsh: exec format error: build/x86_64-unknown-linux-gnu/broot
zsh: exec format error: build/x86_64-unknown-linux-musl/broot
zsh: exec format error: build/x86_64-unknown-netbsd/broot
I believe this error indicates that an executable file is incompatible with my computer's hardware? I have an M1 MacBook running an ARM64 architecture:
❯ uname -m
arm64
Anyway, builds/architecture is outside of my wheelhouse, and I may be misrepresenting the facts.
So any guidance you could provide on how to get these working, else additional labor needed to generate a build compatible with Apple Silicon, would be much appreciated.
@cohml The feature is now part of the standard released broot: https://github.com/Canop/broot/blob/main/CHANGELOG.md#v1252---2023-09-20
Awesome!
This is a great change and I have confirmed that it works for me on both MacOS Ventura 13.4.1 (M1 Pro) and Red Hat Linux.
Sorry to have been unable to assist more with testing before the release.
By the way, not sure if this addresses the original issue here, but it seems like you basically said "no" to that proposal, with no additional movement on it in 2+ years.
In that case, now that a scaled back solution has been implemented, I vote to close this issue.
no additional movement on it in 2+ years
Many issues unfortunately take a long time to be solved because I manage a lot of projects and don't have so much time after work.
And this issue is kind of a painful one because an externally managed crate is involved and that any change would have to be carefully tested on several platforms and configurations to prevent regressions.
I'd rather not close, as somebody may find the time to work on that, but there's no guarantee there's progress soon.
~Although It does not address the original issue, I've just retested and as far as I can tell the directories crate has now been fixed (i.e supports XDG_CONFIG_DIRS). I'm suspecting as a side-effect of https://github.com/dirs-dev/directories-rs/pull/52 but I do not know for certain.~
I didn't test thoroughly enough, I was also using broot --conf in an alias. XDG_CONFIG_DIRS is still not supported by the directories crate. Probably best to leave this open for others who come across it. It should be fixed in the dependency, or by using a different dependency that is also cross platform.
Although I've generally stopped trying to fix these types of issues, I just symlink the many offending tools from the user directory to the XDG directory.