opened
Saul-Dickson
username_0
### 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"`
Make playx configurable
issue
created
NISH1001
username_1
My anti-argument over that is is that the HOME directory is the safest place to put the cache without having to go ove 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. Let me see if I can hook in those environment variables. Thanks for talking about that. 
I could check the env first and then default to the existing one.
comment
created
deepjyoti30
username_2
@username_1 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 @username_0  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).
comment
created
Saul-Dickson
username_0
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.  <i>The environment variable for that is `PYTHONSTARTUP="/path/to/pythonrc"`, by the way. </i>

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`.
comment
created
NISH1001
username_1
@username_0 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!
comment
closed
NISH1001
username_1
issue