Feature Request: Make config granular

[danisztls]

This is a suggestion for a more granular and easy to setup solution.

1. Have configuration for each program on a partial at /usr/share/xdg-force/.
2. Have a script to link/unlink partials to $XDG_DATA_HOME/xdg-force/.
3. Have a simple hook on .profile or similar traverse the directory and source all linked partials.

Usage:

force-xdg cargo
# Do you want to enable configuration 'cargo'? (y/n)

force-xdg cargo
# Configuration for 'cargo' is already in place, do you want to remove it? (y/n)

I have something similar in my dotfiles.

https://github.com/danisztls/dotfiles/blob/main/shell/profile#L73=
https://github.com/danisztls/dotfiles/tree/main/shell/config

[mazunki]

Great idea! We were considering adding USE flags for Gentoo to deploy each of the symlinks here, too.

How do you suggest we keep track of which files are maintained by force_xdg?

Ideally, /etc/env.d/99-force_xdg is the best place to keep the environment file, but a solution for userprofiles is also part of the goal. As you say, said file should be configurable, as to not overload the environment with unneeded/unwanted stuff.

There's also the issue of some fixes being set for programs which are not installed at all. Not exactly sure how to sync this up on new installs, other than requesting the user to run force_xdg update or similar on each update. I like the new command :)

[danisztls]

I'm not familiar with Gentoo and I'm biased by Arch. On arch it would make sense to have the recipes on /usr/share/force-xdg I guess. There's also /etc/xdg for default configuration.

How do you suggest we keep track of which files are maintained by force_xdg?

I think symlinks are fine and maybe Stow is useful.

There's also the issue of some fixes being set for programs which are not installed at all.

On Arch it's possible to add hook a to the package manager (to update links each time a package is installed/removed) and it's possible to run pre/post-install scripts when installing/updating/removing force_xdg. Though this is distro dependent. I think it makes more sense to have a database of recipes and then figure out packaging for each distro.

[mazunki]

Yes, /usr/share/force_xdg for the recipes is sane. /etc/force_xdg for living configuration is also sane. This is the FHS standard, and is (should be) standard across all distros. For user configuration this is respectively ~/.local/share/force_xdg and ~/.config/force_xdg.

Even on Arch, /etc/profile and /etc/env{,.d} should be present. It's part of what Bash and friends use as part of their default configuration, and as thus is the system-wide standard for presenting an enviornment to the user(s).

I think symlinks are fine and maybe Stow is useful.

I tried Stow, but never really liked it. Maybe I didn't try hard enough.

On Arch it's possible to add hook a to the package manager (to update links each time a package is installed/removed) and it's possible to run pre/post-install scripts when installing/updating/removing force_xdg. Though this is distro dependent.

Adding pre/post-hooks to scripts is also possible in Gentoo, and if the package(s) support it that's the way to go. On Gentoo these hooks can further be controlled by the use of USE flags, as if they were arguments controlling conditionals. I don't think that's possible on Arch, without the use of a custom PKGBUILD overlay.

I think it makes more sense to have a database of recipes and then figure out packaging for each distro.

Yep, those recipes were exactly what I was thinking should go into data_home/env.d/. By running make install (or the corresponding PKGBUILD/ebuild install script), the idea is that the attributed yes/no configuration generates the proper /etc/env.d/99-force_xdg or similar script.

Does this sound sane to you too?

[mazunki]

Alright, I've pushed all of the environment variables we had in environment, plus the ones you provided from your config @danisztls (thank you), into the new data_home/force_xdg/env.d/ directory.

I'll see if we missed some from the Arch Wiki, and add them too.

The idea from this point is to have a config_home/force_xdg/config in which we can specify which files from the env.d we want to activate/deploy to our system. Once we have a configuration, we can generate a single sourceable environment file, which is deployed in the location the user best wants it. Personally I would suggest /etc/env.d/99-force.xdg for systemwide fixes, but user-installs should also be possible.

What's a desirable way to specify the configuration? The simplest implementation would just be a file ~/.config/force_xdg/activated, with a list of all the active ones, I think.

[mazunki]

Note that I didn't implement any fixes from your configuration where you used aliases yet. I also took the liberty of changing some of the locations/filenames you used. I added some TODO labels, I'd appreciate a runthrough on them.