Make playx configurable
Closed this issue · 4 comments
The Problem
All over the playx README.md it says "by default" for the location of caches and logs, but nowhere does it say anything about changing these defaults. Looking at the source code, it can't. At least, not without changing the hardcoded paths in each file.
Why is not having these paths easily changeable such a problem? Well, for one, it's implied in the -p option that it's configurable when it's not, and for two; no program is important to such a degree that it should clutter the user's home directory. The only things that should be in the home directory are .local, .cache, .config, and the other XDG-HOME directories, with only the exceptions of startup commands for shells and the like (ie. .zshrc, .bashrc, .zshenv).
The Solution
There are many possible solutions to this problem, though many of them are overkill and unnecessary for a program like playx. Some of these configuration options which are overkill include, but are not limited to: a configuration file, a configuration subcommand in the program itself, an argument for specifying the location of the cache. All of these are either redundant or unneeded.
The solution that I think is best for playx would be to use shell environment variables defined in commonly used files such as .zshenv or .bash-profile, or on a case-by-case basis in the shell itself. They're simple, well understood by people who would want to move playx's cache and log files elsewhere, and easy to put into the code, though I'm not going to go into how here. The commands for setting these variables would look something like this:
export PLAYX_CACHE_HOME="$HOME/.cache/playx"
export PLAYX_LOG_HOME="$HOME/.local/share/playx"
"The only things that should be in the home directory are .local, .cache, .config, and the other XDG-HOME directories, with only the exceptions of startup commands for shells and the like (ie. .zshrc, .bashrc, .zshenv)."
My anti-argument over that is is that the HOME directory is the safest place to put the cache without having to go over privilege issues. (Of course, you could give some privilege to playx.) Plus, the most feasible one since it will be independent of any other paths.
But I totally agree with using the environment variables. Let me see if I can hook in those environment variables. (The codebase is messy with hard-coded paths. Might take time). Thanks for bringing that.
I could check the env first and then default to the existing one.
@NISH1001 Another option would be to use the ~/.cache directory instead? We can just create a playx directory inside it and store everything. While that could be the default, we should totaly give the user freedom to decide where the cache can be stored.
In terms of the env variables, it seems like going with a config file would be better because that would be, in a way, future proofing for other options that we might let the user configure own their own in the future?
But, I feel like what @Saul-Dickson has said is not wrong, even when we shared playx on Reddit, some users pointed this out that using the home directory ain't cool, especially for our userbase which consists of most people using Linux who won't be comfortable with one extra directory in their home (that includes me).
My anti-argument over that is the HOME directory is the safest place to put the cache without having to go over privilege issues.
Not really. .config .cache and .local are privilege free zones on most, if not all, distros. That, and the idea that storing these files in the home directory is the most "safe" something I disagree with. An annoying new folder to clutter the home directory, especially for a new user who doesn't really have any investment in the application, would put anyone off. When I first downloaded it, I was newish to Linux and was more-or-less just messing around.
Now? I spend most of my day, usually at my own detriment, customizing and optimizing my dotfiles to ensure my home directory is as-clean-as-possible. I've even gone as far as to modify where my .python_history file is stored. The environment variable for that is PYTHONSTARTUP="/path/to/pythonrc", by the way.
Getting back on topic, saying permissions is a problem is absurd. I have never, not even once, had to give a program permissions to create configuration files in .config, data files in .local/share, or-- and this would be one of the most counter-intuitive, unnecessary measures in any kind of program, let alone an OS-- cache files in .cache.
@Saul-Dickson Sure!
I surely know how this work
(let me be egocentric right now as a long-standing Linux user with a narrative of "been there done that" in a lot of customizations and writing a lot of low-level things...)
Now, as someone who has obviously seen a lot of scripts making ~/.applicationname, I digress. However, I agree that users should be able to customize the paths where things are stored. And of course, nothing has right/wrong in this regard with preferences. I don't mind my home directory being polluted, especially when the directories are hidden away most of the time unless I want to cd into them. And of course, .config and .cache are the off-the-shelf places. But standards and preferences shouldn't really clash for me as a user.
Regarding the issue on customizing the "paths" in the codebase might take time. Have patience. Or I'd be happy to get a PR. The codebase sucks and it feels like going into a very dark maze. ( It'd be long before I entirely dump playx development itself since it requires me to allocate time on working on this). Probably, people sending PR will themselves dump playx because of code-smell and write similar "tool" themselves. I let that be!
Gonna close this issue since it's not that much productive other than suggesting to customize paths which I strongly agree with!