Better imports

[shtlrs]

I have seen a pattern where certain modules are imported from within functions.

This is usually used as a hack to avoid circular imports, which brings the question of why we have them like that ?

This pattern has caused the e2e tests to fail in #229 ( see all of my comments)

The erros is mostly do to unusual binding of values inside modules/ to variables, which can lead a variable to have 2 states at runtime, whereas we only want it to have one across the entire app's lifecycle.

[supakeen]

So, this is related to #232. Those imports aren't there to prevent circular imports but they are there to make sure those modules only get imported after the configuration is setup.

I'm unsure if we want to close this as a duplicate or track separately.

[shtlrs]

So, this is related to #232. Those imports aren't there to prevent circular imports but they are there to make sure those modules only get imported after the configuration is setup.

I'm unsure if we want to close this as a duplicate or track separately.

How keen are you on keeping the configuration as simple variables like this ?

I was thinking about using pydantic models, for the following reasons:

1. We'd have a better structure for configs.
2. It's easier to patch class instances, or even replace them.
3. Pydantic comes with a native support of loading from the environment AND from .env files.
4. Something that can be used in Override configuration through CLI #232: Defining options as some sort of objects, that we'd load from these model classes. The advantage is that we get to access both the variable names and its metadata: types, etc. That we can use later to inject into click types / converters.

[shtlrs]

This has been fixed in #239