Open mikebaumann opened 6 years ago
One possible approach to resolution is to provide a variation on the recommended initialization code:
config = HCAConfig()
config['DSSClient'].swagger_url = "https://dss.example.com/v1/swagger.json"
client = DSSClient(config=config)
in which the line:
config = HCAConfig()
provides a config with only the default configuration, as is obtained internally from: default_config.json
, which consists of:
{
"log_level": "INFO",
"client_id": "foo",
"DSSClient": {
"swagger_url": "https://dss.data.humancellatlas.org/v1/swagger.json"
}
}
In this case, potentially erroneous values for application_secrets
and oauth2_token
would not be implicitly loaded.
Another approach is to allow provision of an alternate name for the configuration, in which case the existing "hca" configuration would not be implicitly loaded. Although tweak supports this, the current HCAConfig implementation prevents an alternate name from being specified.
def __init__(self, *args, **kwargs):
super(HCAConfig, self).__init__(name="hca", *args, **kwargs)
This can be monkey patched around, as is being done for a temporary interim solution, here:
def monkey_patch_hca_config():
HCAConfig.__init__ = HCAConfig.__bases__[0].__init__
Setting the HCA python bindings to alternate DSS as currently documented:
works in contexts in which there is no preexisting HCA configuration, as is typically the case when the HCA python bindings are used within a deployed Lambda.
Problems arise, however, when setting the HCA python bindings to an alternate DSS in a user context, as when running scripts or unit tests that reference a specific DSS, and there is preexisting configuration for the DSS. Depending on the specific use case, it may be desirable to use Google user credentials or GOOGLE_APPLICATION_CREDENTIALS, yet the issue being raised here applies to both cases.
Here is a sample scenario:
~/.config/hca/config.json
In this example, theconfig.json
has the default values as would be populated by runninghca dss login
and selecting the user's credentials (or similarly running anyhca
command that requires authentication with GOOGLE_APPLICATION_CREDENTIALS configured, in which case theoauth2_token
value would not be present in the following):Although not obvious from the code above, this will implicitly load existing HCA configuration (including
application_secrets
and (if present)oath2_token
) then set ahost
value that is incompatible with these existing values. This will result in the following inconsistent configuration, as the host has changed but theapplication_secrets
andoauth2_token
) have not:In addition, per the currently specified initialization code, this inconsistent configuration will be persisted to the current configuration file (
~/.config/hca/config.json
or file referenced byHCA_CONFIG_FILE
) when the python program exits).If using Google user credentials, these inconsistencies can be corrected by performing an
hca dss login
command again. Yet, if using GOOGLE_APPLICATION_CREDENTIALS, the inconsistentapplication_secrets
currently appear to remain inconsistent.