Open dbarnett opened 1 month ago
Or maybe instead of separate configs per account, the config.toml structure should change to support e.g.
[accounts."account1@domain".calendars]
ignore-calendars = ["cal1", "cal2"]
?
I hit one snag that the oauth tokens we receive don't seem to include an account name or email to identify separate accounts. It seemed like the openid
and …userinfo.email
scopes might help get that included (relevant OAuth docs), but I haven't quite figured out how yet, and requesting more than one scope seems to make the auth flow more complicated with checkboxes on the scopes you have to make sure to manually check.
Alternatively we could just let users manually name the accounts and store one unnamed one as "default", like:
$ gcalcli init
…
Successfully loaded credentials for account "default".
$ gcalcli init --account=work
…
Successfully loaded credentials for account "work".
K for reference, I was able to successfully fetch account ID / email using their recommended way from google_auth_oauthlib docs:
flow = InstalledAppFlow.from_client_config(
…
scopes=[
"openid",
"https://www.googleapis.com/auth/userinfo.email",
"https://www.googleapis.com/auth/calendar",
],
)
session = flow.authorized_session()
profile_info = session.get(
'https://www.googleapis.com/userinfo/v2/me').json()
but I can't figure out how to get it to require multiple scopes like that w/o the annoying checkboxes and am leaning towards just letting users explicitly assign names to the accounts like gcalcli init --account=someaccount2
.
I like the idea of using an --account
flag to define the location of the oauth/config files. Previously, I ran two commands in my conky config to see calendars from two separate accounts. An --account
flag should allow my use case to work again, provided the flag works with other commands like list, agenda, etc.
[accounts."account1@domain".calendars]
This seems unnecessarily complicated to me. Having a different toml files for each account is a lot easier to understand. If you want to avoid duplication in configuration, it maybe be better to have config.toml
included by default, with any changes in other.toml
overwriting it, but others copying the config.toml
configuration.
Eh, could be I'm overcomplicating things. My priority in however it's specified is to remove any temptation for people to manually twiddle oauth files, so we're not locked into some implied contract of where these files need to live.
How would these "config.toml" and "other.toml" files be specified when you're invoking gcalcli though?
config.toml
would be the default.
For other.toml
, options could be:
--config=other.toml
--config=other
--config=account@domain
(and the file would need to be called something like account@domain.toml
)Might work okay. I suspect that'd also end up having a lot of complications in practice:
ignore-calendars
?Granted these are all details that need to be figured out for pretty much any strategy, but could start getting really messy really fast using implicit mappings or magic names.
I agree with --config=other.toml
being a good way to invoke another instance.
In an ideal world, if I ran gcalcli init --config=sports.toml
a new config called sports.toml
would be created with a reference to that specific account auth token. Then, in the event that any subcommand is issued with the --config
flag, it would refer gcalcli to that instance (meaning the secondary config would "replace" rather than "extend" options like ignore-calendars
. They would be completely separate instances.
Ultimately, I'd think that the .toml
would need to have an explicit reference to the account auth token to ensure 1-to-1 mapping.
Upon reflection I think --config=other.toml
is the best option as it makes it easiest for the uninitiated to understand what is going on, and enables config files outside the standard config directories if a full path is supplied.
gcalcli init --config=sports.toml
Good idea! Should be gcalcli --config=sports.toml init
though 😉
K then a few things:
--account-config
or something?BTW the recommended way of pointing to an explicit config file / dir is $GCALCLI_CONFIG
and that should be fine as-is. Could use an env var for this account config thing too, but I kinda prefer an explicit arg for the init
case.
I also realized init
could just prompt you for whether to overwrite the default account or set up an alternate. That would make it friendlier having it suggest new file paths you could edit instead of having to figure out everything upfront as cli args.
There should be a convenient way for users to switch between different authenticated accounts in gcalcli.
Currently this can be done by twiddling oauth files (see #805), but the mechanism is clunky and not very discoverable. The ideal would probably be to have a set of named auth accounts and to be able to configure
--account=someaccount@domain
in cli args and config files.