leclercb / taskunifier-app

TaskUnifier - Task Management Application
https://www.taskunifier.app
Other
27 stars 7 forks source link

Ability to override "dataFolder" with environment variable #196

Closed szpak closed 4 years ago

szpak commented 4 years ago

Is your feature request related to a problem? Please describe. I would like to be able to have two set of tasks (test tasks and production tasks), for example to separate personal and company tasks (or to some experiments with the devel version without the risk to corrupt the production tasks).

Describe the solution you'd like Currently, it seems that TU calls app.getPath('userData') https://github.com/leclercb/taskunifier-app/blob/6220ecea36eb484aa39a280b4d69357d8d1c3514/public/electronUtils.js#L107 to get the directory where coreSettings.json is located. On Linux it is always ~/.config/taskunifier-app. For playing with the devel version it would be good to define the environment variable (e.g. TASKUNIFIER_USER_DATA or TASKUNIFIER_HOME) to tell TU to user specified folder (and fallback to the aforementioned in not defined).

It is a common pattern in the Linux world to have more than one data set.

Extra comment I'm aware of dataFolder, but it can only be used to relocate data (not use two of them interchangeably). If the new environment variable is defined, TU should set dataFolder to that directory for the first, initialization execution.

leclercb commented 4 years ago

Hello,

I understand what you mean, this could actually be done writing a simple 2 lines bash script replacing the dataFolder property in coreSettings.json (with "sed" for example) before starting TaskUnifier.

Between a script changing the environment variable that TaskUnifier would have to take into account and writing a script changing the variable in coreSettings.json, there is no real difference in my opinion.

What do you think ?

szpak commented 4 years ago

It could be done that way, however, the solution with the environment variable is safer and more clear for the user. There is no risk of broken configuration (assuming for example TU crash which leaves the configuration not reverted) and it would be harder to build a portable distribution of TU (e.g. to keep it with you on a pendrive with all tasks placed on that pendrive as well). What's more, defining the environment variable for that home/data directory is quite common (and natural) for Linux people (e.g. GnuPG or Kubernates). With the environment variable, it should be also possible to run two instances of TU simultaneously (e.g. personal and work tasks).

Assuming I was able to convince you ;-), in wonder, if it would be required to just try to read that variable once and keep that value (or the fallback ~/.config/taskunifier-app) in some variable to be used down the line instead of just ~/.config/taskunifier-app or there are more places in TU to change?

leclercb commented 4 years ago

The user data path will not change, this one is fixed and cannot change. But as you said it only contains the coreSettings.json, which contains the data folder location.

What I did now, is:

If the env var TASKUNIFIER_DATA_FOLDER is set, then the data folder will be that one. Otherwise, read the data folder location from the coreSettings.json

This will allow you to start TaskUnifier with an env var and easily switch the data folder location.

I hope that's what you requested :)

szpak commented 4 years ago

Yes, my case with an extra data folder to test is covered. Thanks!