Variable oauth storage location

[ahughes03]

I used to be able to store oauth files alongside config/cache in a folder of my choosing. It now appears that with --config-folder being depreciated, $GCALCLI_CONFIG only stores the .toml file in the folder of my choice. It does not, however, allow for storage of the oauth file in a location other than ~/.local/share/gcalcli/oauth.

I previously used gcalcli to pull multiple calendars from different accounts, and without being able to set the location for the oauth storage, I'm only able to pull one.

Is there a command I'm missing that will allow the oauth storage location to be set variably?

[dbarnett]

Huh, that's an interesting use case...

For now, I guess it shouldn't be too hard to support an env variable, flag, or an option within the config file... which seems the most ergonomic for your use case?

Longer term, I'd imagine managing different auth accounts by name instead of twiddling files, something like the way gcloud auth works, and making the options select the account name instead of pointing to raw auth storage files.

[ahughes03]

I like your longer term suggestion, it seems the most streamlined and intuitive.

For the short term though, is there a reason that calling the $GCALCLI_CONFIG env variable can't also trigger storing the oauth file in that same specified location? To me, that makes the most sense- if I'm specifying a folder to store config, that's where I'd expect all things related to that config to reside. If that's not an option, I'd think utilizing an option in the config file would make the next most sense.

[dbarnett]

Yeah, I think I was coming to the same conclusion, that it might as well pick up oauth files in the same config dir if they exist.

The downside is just the complexity of long chains of fallbacks: already there's quite a series of legacy paths the file can exist at, and e.g. it's kinda hard to explain recommended usage in the help to make the mechanisms discoverable and comprensible for anyone who may need them. Especially with --config-folder vs $GCALCLI_CONFIG it gets messy because it can technically get recursive (with that path specifying a different --config-folder).

But for now at least the code is no worse than it was previously if it's just restoring some supported paths that already existed, so I'll work on restoring some mechanism along those lines.

[dbarnett]

K, are you able to test against the latest repo version that #806 fully solves your issue?

[ahughes03]

I checked out the latest commit and forced a reinstall using pipx install --force gcalcli. I'm trying to run the following command to init two calendars:

GCALCLI_CONFIG=~/.config/gcalcli/ gcalcli init
GCALCLI_CONFIG=~/.config/gcalcli-sports/ gcalcli init

The first command works fine, but when I run the second one, it's telling me that the credentials are already configured, meaning the oauth is stored separate from the config dirctory I specified.

I have a feeling I'm doing something wrong to trigger the oauth file being stored in the specified folder, since the oauth is still at ~/.local/share/gcalcli/oauth.

[dbarnett]

The oauth files aren't placed in config by default, just if you manually drop the files into config they should take precedence over global files.

Granted, nothing in the app explicitly tells you where to find the oauth files to move them, but I'm only intending this as a stopgap solution to unblock your case in the short term.

[ahughes03]

No dice- I moved the oauth file into ~/.config/gcalcli/, verified it's there, and then ran GCALCLI_CONFIG=~/.config/gcalcli/ gcalcli list, and was greeted by the Not Yet Authenticated message. I'm still showing as on commit:521bf2a and did another force install to ensure I'm working with the correct version.

Anything else I could be missing? I think I must be doing something wrong: gcalcli --version still shows 4.5.1, but I'm definitely trying to build/install out of the correct commit (I can see the 4.5.2 note in the changelog file.

[dbarnett]

Yeah, that just sounds like not having the repo version successfully installed. --version should say something like 4.5.2.dev1+g521bf2a.

What I usually do to run the repo version is to create a virtualenv, source the activate file, and then pip install .[vobject] into the virtualenv.

Anyway I'm pretty sure that mechanism works as intended if you just wait to use it in the release version. The only thing that's a little iffy still is discoverability, but I'm not sure how much effort I want to put into making this stopgap mechanism easy to use.

[ahughes03]

Thanks- I'll wait for the push to 4.5.2- I did skim the changes in the commit and saw all the work. Much appreciated!