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
This issue arose while attempting to get stdatamodels tests to run locally (fix and semi-related discussion in: spacetelescope/stdatamodels#117).
A set of tests including a local import of crds always failed after the first call. This was traced back to a use of CRDS_REFERENCE_URI that returned None instead of 'none'. Here's a reproducer:
importosimportpytest@pytest.fixturedefjail_environ():
"""Lock changes to the environment"""original=os.environ.copy()
try:
yieldfinally:
os.environ=original@pytest.mark.parametrize('value', ['1', '2'])deftest_crds(jail_environ, value):
importcrdsassertcrds.core.config.CRDS_REFERENCE_URI.get() =='none'
If the import crds is moved outside the test (and no longer 'jailed' by the fixture) the tests pass without issue.
I'm not certain if this is a crds bug as crds might assume that the environment variables are unchanged between calls. A minimal reproducer (without pytest is):
The 'issue' isn't seen with an unmodified environment because the first call to StrConfigItem.get occurs within StrConfigItem.__init__ and the return value is thrown away. This call also sets the environment variable so future calls to StrConfigItem.get return the expected 'none'.
I think the issue could be addressed by changing these None values to 'none' (but am not familiar with the inner workings of CRDS to predict any knock-on effects).
This issue arose while attempting to get stdatamodels tests to run locally (fix and semi-related discussion in: spacetelescope/stdatamodels#117).
A set of tests including a local import of crds always failed after the first call. This was traced back to a use of CRDS_REFERENCE_URI that returned
None
instead of'none'
. Here's a reproducer:If the
import crds
is moved outside the test (and no longer 'jailed' by the fixture) the tests pass without issue.I'm not certain if this is a crds bug as crds might assume that the environment variables are unchanged between calls. A minimal reproducer (without pytest is):
The 'issue' isn't seen with an unmodified environment because the first call to
StrConfigItem.get
occurs withinStrConfigItem.__init__
and the return value is thrown away. This call also sets the environment variable so future calls toStrConfigItem.get
return the expected 'none'.crds/crds/core/config.py
Line 139 in 4b19990
I think the issue could be addressed by changing these
None
values to'none'
(but am not familiar with the inner workings of CRDS to predict any knock-on effects).crds/crds/core/config.py
Lines 735 to 749 in 4b19990
The text was updated successfully, but these errors were encountered: