Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config structure #95

Open
barneydobson opened this issue Mar 15, 2024 · 0 comments
Open

config structure #95

barneydobson opened this issue Mar 15, 2024 · 0 comments
Labels
refactor Refactoring existing code without significantly changing functionality

Comments

@barneydobson
Copy link
Collaborator

barneydobson commented Mar 15, 2024

Since have nested and rather complex config structure, this approach is not suitable. You should have a custom class for this using dataclass for example, since working with nested dict objects is difficult and not maintainable. I know you're in a time crunch and want to produce results as soon as possible. But I highly recommend refactoring this part. So, for example, instead of having config['real']['results'], you can have something like this:

@dataclass
class RealModel:
    inp: Path
    graph: Path
    subcatchments: Path
    results: Path

    def __post_init__(self)->None:
        self.inp = Path(self.inp)
        self.graph = Path(self.inp)
        self.subcatchments = Path(self.inp)
        self.results = Path(self.inp)
        for f in (self.inp, self.graph, self.subcatchments, self.results):
            if not f.exists():
                 raise FileNotFoundError(f)
@dataclass
class ModelConfig:
    real: RealModel

So, whenever you want to use it in the code, you can use config.real.results. You can have validations and conversions, if necessary, in __post_init__. Having a structure for config even makes development and maintenance easier, since most IDEs now use them for autocomplete suggestions and static type checkers will be able to catch errors.

As I said, if you don't have time to refactor this now, it's ok, it's not a blocker for me.

Originally posted by @cheginit in #83 (comment)

@barneydobson barneydobson added the refactor Refactoring existing code without significantly changing functionality label Mar 15, 2024
@barneydobson barneydobson changed the title Avoid nesting in config config structure Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Refactoring existing code without significantly changing functionality
Projects
None yet
Development

No branches or pull requests

1 participant