-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use XDG_CONFIG_HOME
as default or additional location of config file
#65
Comments
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 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 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:
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, 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. 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 Certainly it's not an option to actually change the path so that it breaks the program for everyone who is using 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 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 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. |
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 But it was not my intention to propose My goal is just to allow users to customize their
And, as you said it:
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":
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:
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. |
Addressing some specific points you made:
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.
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.
But that would obviously also prevent any settings customization in
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 might not affect the actual function of
Not if we push all bumps towards under the same carpet. The fewer bumps the better. Yes,
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.
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.
True, but I've never intended to break anything for anyone.
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.
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.
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.
It does make a real difference, the same way we separate |
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?The text was updated successfully, but these errors were encountered: