If a user does not set the LEAPSECOND_FILE_ENV, but instead furnishes a leapsecond kernel then there is a curryer error:
RuntimeError: Static kernel creation failed: Unable to find the default leapsecond kernel file. Searched directory:
This comes from write_from_json in create.py line 150 on the properties = properties_cls(**properties_def["properties"], relative_dir=parent_dir) call.
From my initial investigation there is an inherent looking through "generic" kernels and relative folder paths that implicitly happens in the background in some of the setup commands for curryer.
How to recreate:
In libera_utils repo. Comment out the environment variable setting in the KernelManger class kernel_manager.py and then run the test_static_kernels_loading integration test in integration/test_kernel_manager.py The kernel manager will explicitly furnish the leapsecond kernel in the _create_static_kernels method, but without the environment variable this errors out.
If a user does not set the LEAPSECOND_FILE_ENV, but instead furnishes a leapsecond kernel then there is a curryer error:
RuntimeError: Static kernel creation failed: Unable to find the default leapsecond kernel file. Searched directory:This comes from
write_from_jsonin create.py line 150 on theproperties = properties_cls(**properties_def["properties"], relative_dir=parent_dir)call.From my initial investigation there is an inherent looking through "generic" kernels and relative folder paths that implicitly happens in the background in some of the setup commands for curryer.
How to recreate:
In libera_utils repo. Comment out the environment variable setting in the KernelManger class
kernel_manager.pyand then run thetest_static_kernels_loadingintegration test inintegration/test_kernel_manager.pyThe kernel manager will explicitly furnish the leapsecond kernel in the _create_static_kernels method, but without the environment variable this errors out.