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
The --config and the default no config option uses different code base for parsing headers. We need to converge the code base and get rid of builderconfig.py and perhaps internally use the default config that applies to most of frepp output. We discussed this over an email thread but logging an issue here as this becomes important to resurrect so maintenance and troubleshooting becomes easier.
Pasting email thread with user suggestion and this implementation approach is worth checking out. It solves the above issue and also the way users could check out a particular config that fits their use-case, without having to clone the repo or access something outside of catalogbuilder conda package.
The configurations live in a resources directory in the package tree. See here.
When the script loads the config file, it uses the package metadata to figure out where this directory actually lives on the user's system:
The advantage here is that the default configuration YAML file is always defined relative to the package installation. The means that when you distribute it via conda or PyPi, there will be predictable behavior.
The text was updated successfully, but these errors were encountered:
The --config and the default no config option uses different code base for parsing headers. We need to converge the code base and get rid of builderconfig.py and perhaps internally use the default config that applies to most of frepp output. We discussed this over an email thread but logging an issue here as this becomes important to resurrect so maintenance and troubleshooting becomes easier.
Pasting email thread with user suggestion and this implementation approach is worth checking out. It solves the above issue and also the way users could check out a particular config that fits their use-case, without having to clone the repo or access something outside of catalogbuilder conda package.
The configurations live in a resources directory in the package tree. See here.
When the script loads the config file, it uses the package metadata to figure out where this directory actually lives on the user's system:
import importlib_resources
config_path = importlib_resources.files("gfdlnb.resources").joinpath("config.yaml")
The resource directory is declared in the package configuration (pyporoject.toml):
[tool.setuptools.package-data]
gfdlnb = ["resources/config.yaml","notebooks/ocean/*.ipynb"]
The advantage here is that the default configuration YAML file is always defined relative to the package installation. The means that when you distribute it via conda or PyPi, there will be predictable behavior.
The text was updated successfully, but these errors were encountered: