Open jambonrose opened 7 years ago
To clarify my last statement: the act of wrapping or unwrapping with a try...except
block misses the point I was trying to make. The goal is to inform the user/developer of what went wrong, and where, helping avoid frustration when first using GBDX.
So there are 3 problems:
Can you give an example of this last one?
This first one is getting fixed in #24
Hi, If there's a credential mismatch in either the
~/.gbdx-config
INI file or any of the environment variables (GBDX_USERNAME
,GBDX_PASSWORD
,GBDX_CLIENT_ID
, andGBDX_CLIENT_SECRET
) thengbdxtools
will fail cryptically or silently.For instance, in the event a typo has been introduced in
GBDX_PASSWORD
, then the program will tell you to create~/.gbdx-config
(rather than tell you your credentials are wrong). In the event a typo is introduced in this config, then the program returnsInvalid credentials or incorrectly formated config file at ~/.gbdx-config.
It's not clear what the problem is.Attempting to run the code again will yield no output, even during failures. A repeat call to
session_from_kwargs
with different credentials therefore seems to work, even when it does not. Using any code after that raisesNonetype
errors, as the session isNone
.In the event credentials fail, the user should be warned of the failure explicitly.
Using logging, it looks as though the error raised by
fetch_token
(in any of the session calls in this project) isoauthlib.oauth2.rfc6749.errors.MissingTokenError
, which is a rather strange error to raise when an HTTP 401 is returned (particularly given that this is an attempt to get a token). It would be nice to wrap these calls withtry...except
blocks to catch this error and inform the user of the probable failure in their config.