Closed JoanneBogart closed 1 month ago
Thank you, @yymao !
One change I made after the discussion some weeks ago was to automatically activate the cfg-file mode of access in case the dataregistry code is not available. This makes it possible to at least test that, in this case, everything behaves as expected for existing applications. If you have code lying around which exercises anything beyond the CI tests and which involves minimal effort on your part, please run it and let me know if you see any glitches.
However users who can successfully import dataregistry will have to make a call to set_config_source
before they can do anything else.
I don't have other tests beyond the existing CI tests.
I wonder if it's useful to add a CI test to check the functionality of dr_register.py
?
I wonder if it's useful to add a CI test to check the functionality of dr_register.py?
It would be useful but would take some work since the CI workflow has no access to NERSC resources, including the data registry Postgres database. We would have to create a database as part of the workflow and add entries. This kind of thing is done for the dataregistry CI.
I have a test script which I used to debug after seeding a Postgres database at NERSC with some entries.
dataregistry does also support sqlite to some degree. I might be able to use that for a more self-contained test. This is something I should look into after we have made a release of the dataregistry with all the support needed so that CI can easily install it.
If the dataregistry module is available in the user's environment, they can choose to use it to find and load catalogs instead of the traditional config file mechanism.
fix #637