Use `XDG_CONFIG_HOME` as default or additional location of config file

[Rodrigo Silva]

Vex is an amazing tool, and I'm very interested in using it in a large scale of systems.

But the default ~/.vexrc as a config file location nowadays is really frowned upon. And it's a hardcoded path, with no support for an env var to modify it. Python, Pip, Git and most software use the XDG Base Dirs such as ~/.config and ~/.local for the settings and data.

Would you guys be interested in a patch to also reads from the more standard ~/.config/vex, instead (or in addition to) the current location?

[Sasha Hart]

Thanks for your feedback.

It's just me. There is no vex committee. Neither I nor the project have any affiliation with the Python org. No prestige attaches to being a contributor on vex.

Short answer: no patch is needed because it's trivial to implement - and I don't think it's necessary. Sorry. I will consider it in the future. However, I really think your purpose might be better met by simply not using a .vexrc and thereby avoiding any file in $HOME (even under .local).

Long answer:

I'm glad you enjoy the program. While I made it for myself, I'm glad it can be useful to other people. This is why I donate unpaid labor to maintain it. However... I get no actual benefit if you use vex, and I get no actual harm if you don't. If you used a different program due to your personal feelings about the path of the config file, that wouldn't bother me at all.

As I've said from the beginning of this project, vex is more of a replacement for shell scripts that munge the current environment: instead of modifying the environment, run a process in a new environment. However, virtualenvs are in themselves relatively trivial and you can always run env/bin/python, so use whatever suits your purposes! Personally I would only use vex for interactive purposes. In larger systems I wouldn't use vex or anything like it, I would just directly use the virtualenv without adding extra layers - or I'd already be using a container.

vex reached its goals of functionality and maturity years ago and is now in maintenance mode. Literally any change to this old project has the potential to cause problems after it is distributed by PyPI. Meaning three things:

1. a larger number of people experience the actual effects of an actual bug,
2. I take all the blame, and
3. I do all the work to fix it.

The benefit of a proposal has to outweigh that risk, or it's not worth it. So as a maintainer, I manage this little project conservatively. Some might say too conservatively - but it's not their project.

Crucial point here: the person writing an issue or even a pull request does not bear these costs at all. They want a change made, but they don't bear the costs and they don't internalize the effects on other users. This creates an inherent conflict of interests between the proposer and the project owner. That conflict is dysfunctionally resolved if maintainers take every request, meaning either the project's quality goes to shit or the maintainer spends all their project time babysitting and cleaning up the messes of people who have little to no stake - a recipe for burnout. The functional resolution requires proposers to achieve some empathy and think like maintainers.

Bearing this in mind, let's return to the subject of changing config file paths:

I don't see that the benefit outweighs the costs.

To be clear, what you have reported is not a bug. It doesn't affect the actual function of anything. Rather, it's a matter of fashion. Which changes often: it was different in the past, and it will be different again in the future. And often the driver of the fashion is something silly, like courtiers imitating a King. There is no inherent value to fashion, it just marks something as being made during a certain time and perhaps by a certain community. That has nothing to do with the reason I created vex (functionality I needed) nor why I shared it. If vex seems unfashionable to you, that's fine with me. Python isn't fashionable, Linux isn't fashionable, etc.

This config path is at best a matter of personal aesthetics. And there's no disputing taste. Perhaps for you, ~/.vexrc feels like a horrible blemish. But moving it into another folder makes that folder a mess, so on an "OCD" level we're just pushing around bumps in the carpet. If you have a feeling and I have a different feeling, we don't even really disagree on anything factual.

It's rude to try to shame people into doing what you want solely because their project isn't to your taste. That kind of social penalty should be reserved for people who are actually doing something harmful. ~/.vexrc isn't harmful - it's just not to your taste. And you have options which avoid it.

Standards have no moral authority apart from any usefulness they may have. They don't choose us - we choose them. For example, the "Linux Standard Base" defines RPM as the standard package format, yet many of us use Debian or Arch. Should we instead follow the Linux Standard Base and only use Red Hat? You might be appalled to see what the process of standards creation looks like - quite often, it's just some company throwing its weight around, bulldozing dissenting voices. I don't think we should ever be ashamed of breaking standards when this has no consequences. It's not a moral issue.

Standards promulgated by freedesktop.org only matter to me insofar as they are about interop in the components of windowing system components. I really can't see why an org with that scope should dictate to everyone on *nix how $HOME should be laid out. It has no more force than someone's opinion on what $LS_COLORS should be or what font I should use. They can say whatever they want. It's up to us whether we take that seriously. In the case of vex, which has nothing to do with windowing systems, I don't think it matters.

Certainly it's not an option to actually change the path so that it breaks the program for everyone who is using ~/.vexrc. People want this kind of utility to just work and they're right. It's not like I'm going to tell them to prepare for the breaking change in a newsletter.

Running vex with an environment variable every time (or setting yet another environment variable in shell config) is a mess and I would hate to suggest it as something people should do, or might have to do. vex looks at a conventional place to save specification effort precisely because the whole point of .vexrc is not to have to specify a bunch of crap on every command line, or make a bunch of shell aliases. If the point was to keep $HOME clean then I just wouldn't have any config file. When I created .vexrc I put it in $HOME because it keeps things simple to explain and use and on the same level as other shell stuff like .bashrc and .zshrc. vex is a convenience tool, without convenience it is useless.

On a typical system your home directory is unavoidably full of stuff. Big companies are allowed to make lots of crap files and directories in my $HOME which aren't even hidden. Old projects are allowed to have files like ~/.bashrc. Even if you move .vexrc you are still going to have $HOME full of dotfiles. The main practical effect I can see is that it makes it a bit harder to sync or back up personal stuff as distinct from caches and so on, but people use various tools to mitigate this by maintaining symlinks in the home directory. I wrote an unreleased one for myself. This kind of "mess" is just inherent to systems which are actively used interactively, and the use of $HOME is indigenous to *nix. You can push stuff under ~/.local but it makes no real difference to anything, including how much mess is there. It's just another level of hierarchy.

Comparing that to what it takes for me to make sure this is well tested, I'm not doing it at this time.

But again, thanks for your feedback, and please have a nice day.

[Rodrigo Silva]

Thanks for such a long and detailed reply!

First of all, as a maintainer of other projects I do sympathize with you about the burden that every new feature carries, not on the PR author but on the project maintainer(s). I am fully aware that there is a cost attached. And the benefit must outweigh that cost.

Also, I couldn't agree more with you about standards, specially one dealing with our $HOME: they should be chosen, not enforced, by each one's taste, preference or fashion. And one should choose not because "it's a standard", but if (and only if) it adds some actual value to that person.

But it was not my intention to propose vex should enforce (or even adopt) the XDG Base Dir spec onto its users. I'm merely proposing it could support it for the users that care about it. The ones that don't care won't even be aware of this. It would not change anything for current users. I'm not proposing anyone should change their default, or move their config file, or that Vex should encourage or suggest it. No, not at all! You might have misunderstood my proposal.

My goal is just to allow users to customize their vexrc default path, if they wanted to. If they're happy with ~/.vexrc, then they don't need to bother at all. But, for those that do prefer a different path, currently the only way vex supports is:

vex --config /some/other/path ...

And, as you said it:

the whole point of .vexrc is not to have to specify a bunch of crap on every command line, or make a bunch of shell aliases

My whole proposal is exactly to avoid the "bunch of crap" for people that want to change their config location. It's cumbersome, and it kinda defeats the joy of using vex in the first place, and that ease of use is, I believe, the main point in using vex at all instead of the boring manual activation of virtualenvs.

Tools that deal with config files usually take one (or both) of these approaches to avoid command line "bunch of crap":

• Read from known paths, such as ~/.vexrc
  • (and my proposal can be to merely include ~/.config/vex/vexrc as an additional known path)
  • Again, ~/.vexrc would obviously still be the read, as it always was
• Read from a path set by an environmental variable
  • that was merely a suggestion I made, for/if people care.
  • It allows vex to offer a permanent solution no matter what the user preference is, ~/.config or something else
  • those who dislike yet another env var don't have to set it or deal with it, and just use the current default

So, while the cost to maintain this is concrete (add tests, update documentation, etc), the benefit is somewhat subjective, because we're talking about the perceived benefit of a given feature. And that perception can, and usually does, vary between people. What might be extremely beneficial to some users might be irrelevant for some.

I'm offering to minimize as much of the cost as it possibly can, by making a PR not only with the feature itself but also add any tests and documentation you deem needed, and also to triage any issues that might arise from this. Which, given the "opt-in" nature of this feature, I believe will be minimal, if not none at all.

For me, and I believe for many others, setting the config path offers an imense value, as much as the settings in the config file itself.

Why? Well, you spent great lengths about why this does not add much (or any) value for you. I would be happy to share my thoughts in equal length if you're interested. But in the end, as you've so well put it, there's no disputing taste. So I'll just mention one key opinion:

If the point was to keep $HOME clean then I just wouldn't have any config file

Having config files and a clean(er) $HOME are not, and should not, be mutually exclusive goals. Both add their own (subjective) values. And they can both be pursued independently. And for me there are many practical and functional reasons besides aesthetics.

[Rodrigo Silva]

Addressing some specific points you made:

No prestige attaches to being a contributor on vex.

I never assumed it would. I don't contribute for prestige, I do for things I actually use, to add or fix things that are useful for me. If it's useful to anyone else, then great.

If vex seems unfashionable to you, that's fine with me. Python isn't fashionable, Linux isn't fashionable, etc.

Never said or implied that. On the contrary: I think vex, Linux and Python, are all very sexy :). And useful too. That's why I chose to use them all.

However, I really think your purpose might be better met by simply not using a .vexrc

But that would obviously also prevent any settings customization in vex, which would be so detrimental to its usage that I hope you were being sarcastic. You don't honestly think that my purpose is better met this way, right?

To be clear, what you have reported is not a bug.

I'm fully aware of this, never said it was a bug. In Github, it's all "issues", even sharing the numeration with PRs. It could be classified as a feature request. But I'm not even requesting such implementation, I'm offering it and asking if it would be a welcome addition.

It doesn't affect the actual function of anything. Rather, it's a matter of fashion. [...] And often the driver of the fashion is something silly [...] There is no inherent value to fashion. This config path is at best a matter of personal aesthetics.

It might not affect the actual function of vex itself, but it does affect the function of my system, more specifically backup scripts and other automation tools I use to manage my (and my family's) $HOME. While I realize this is still a personal choice, it is not driven by fashion, or aesthetics alone, but rather also by functionality and interoperability. For me, it's a technical benefit with concrete value.

But moving it (~/.vexrc) into another folder makes that folder a mess, so on an "OCD" level we're just pushing around bumps in the carpet.

Not if we push all bumps towards under the same carpet. The fewer bumps the better. Yes, ~/.config itself might become a mess, but it's a mess of config files only. Kinda like /etc. Which is way better than having ~ a mess of everything

It's rude to try to shame people into doing what you want solely because their project isn't to your taste. That kind of social penalty should be reserved for people who are actually doing something harmful. ~/.vexrc isn't harmful - it's just not to your taste.

Whoaa, that's a lot of things I didn't say or imply or intended to. I'm not shaming anyone, nor I think vex or vexrc is harmful. I'm not even asking anyone to do anything: I'm offering the feature and asking if its welcome.

Standards have no moral authority apart from any usefulness they may have.

I agree. I'm not offering to implement vex's support of XDG on any moral or authority grounds, but precisely because I believe it's useful for vex to support it. Or, rather, it would be useful for me, and possibly other users, if vex did so.

Certainly it's not an option to actually change the path so that it breaks the program for everyone who is using ~/.vexrc. [...] It's not like I'm going to tell them to prepare for the breaking change in a newsletter.

True, but I've never intended to break anything for anyone. ~/.vexrc would still be a valid path, no changes required by any current user. Use as default or additional location is very different than changing the path. There would be no breaking change, no newsletter required.

I would hate to suggest (an environment variable) as something people should do, or might have to do.

You don't. No one will have to. Just the ones that want to change their path. Whoever is fine with the default can keep it.

On a typical system your home directory is unavoidably full of stuff. Big companies are allowed to make lots of crap files and directories in my $HOME which aren't even hidden. Old projects are allowed to have files like ~/.bashrc. Even if you move .vexrc you are still going to have $HOME full of dotfiles.

True. But that doesn't mean vex should increase that "lots of crap files". It could provide an easy, elegant way to avoid further cluttering. For no cost or change to anyone that doesn't care.

The main practical effect I can see is that it makes it a bit harder to sync or back up personal stuff as distinct from caches and so on

That's my main technical reason for choosing to move as many dotfiles to a single place as I possibly can. Every new dotfile must be special-case and included in all backup, sync and other maintenance scripts and tools.

You can push stuff under ~/.local but it makes no real difference to anything, including how much mess is there. It's just another level of hierarchy.

It does make a real difference, the same way we separate /usr from /etc. As for "how much mess is there", the key word is there. Not at / or ~ or a similar root.