You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, users can choose whatever name they like for the config file (though generally we are using names ending in *Config.json). The whole path to this config file is passed to HealthGPS when we start it. This is in contrast to the top-level JSON file for static data, which is always called index.json.
The problem is that if we want to implement #406, there will be no way for HGPS to know what the name of the top-level config file is inside a zip file. We could also require users to pass in the filename separately, but this seems a bit gross.
It might be best just to standardise the filename (e.g. to config.json). We could do this in a backwards compatible way: if users pass in the path to a JSON file that is called something else, we could just give them a deprecation warning.
Am I missing anything @jamesturner24? One downside of this approach is that it will no longer be possible to have multiple top-level config files in the same directory (well, without using deprecated functionality, anyway).
The text was updated successfully, but these errors were encountered:
Having one and only one config with standard name sounds great. Long as we can have many sub config files. If people want to have many toplevel configs in their dir, then they can make symlinks. I'm in favour of this.
At present, users can choose whatever name they like for the config file (though generally we are using names ending in
*Config.json
). The whole path to this config file is passed to HealthGPS when we start it. This is in contrast to the top-level JSON file for static data, which is always calledindex.json
.The problem is that if we want to implement #406, there will be no way for HGPS to know what the name of the top-level config file is inside a zip file. We could also require users to pass in the filename separately, but this seems a bit gross.
It might be best just to standardise the filename (e.g. to
config.json
). We could do this in a backwards compatible way: if users pass in the path to a JSON file that is called something else, we could just give them a deprecation warning.Am I missing anything @jamesturner24? One downside of this approach is that it will no longer be possible to have multiple top-level config files in the same directory (well, without using deprecated functionality, anyway).
The text was updated successfully, but these errors were encountered: