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

ADR on import structure #8500

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Conversation

wouterdb
Copy link
Contributor

Description

  1. Feel free to push commits on this branch!
  2. add your name to the deciders if you want to be active part of the discussion

Self Check:

Strike through any lines that are not applicable (~~line~~) then check the box

  • Attached issue to pull request
  • Changelog entry
  • Type annotations are present
  • Code is clear and sufficiently documented
  • No (preventable) type errors (check using make mypy or make mypy-diff)
  • Sufficient test cases (reproduces the bug/tests the requested feature)
  • Correct, in line with design
  • End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
  • If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

- from that responsibility can be derived its knowledge about the world around it,
- which in turn drives which other modules it "sees"
- keep __init__ light, as it is always imported when a submodule is imported.
- a package can offer an interface module (called now something like `model`/`types`/`__init__`).....
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to add naming guidelines for such interface modules ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about <package_name>_interface or <package_name>_api?
And do we want to encourage using the __init__.py file more for this or does it contradict with the rule keep __init__ light ?

Is this more a case by case thing where the interface can live in the __init__ if it's not too heavy but it should live in its own file as it grows ?

Comment on lines 60 to 65
e.g. consider executor and deploy packages and the new_agent
- executor.executor is the interface package
- deploy imports executor.executor
- new_agent import both the interface and concrete implementations of both executor and deploy (top level)
- deploy doesn't import the non-interface parts of executor because it never constructs executors (it is constructed with a reference to a executor manager, which serves as a factory)
- executor doesn't know about deploy at all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think some names in this example are outdated which makes it hard to follow

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also had a hard time following this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated!

- from that responsibility can be derived its knowledge about the world around it,
- which in turn drives which other modules it "sees"
- keep __init__ light, as it is always imported when a submodule is imported.
- a package can offer an interface module (called now something like `model`/`types`/`__init__`).....
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about <package_name>_interface or <package_name>_api?
And do we want to encourage using the __init__.py file more for this or does it contradict with the rule keep __init__ light ?

Is this more a case by case thing where the interface can live in the __init__ if it's not too heavy but it should live in its own file as it grows ?

Comment on lines +60 to +66
e.g. consider `inmanta.agent.executor.executor` and `inmanta.deploy` packages and the new_agent
- `inmanta.agent.executor.executor` is the interface package for the executor framework
- `inmanta.deploy` is the package containing the scheduler (it has no external interface package)
- `inmanta.deploy` imports `inmanta.agent.executor.executor`
- `inmanta.agent.agent_new` imports both the interface and concrete implementations of both executor and deploy (top level)
- `inmanta.deploy` doesn't import the non-interface parts of `inmanta.agent.executor.executor` because it never constructs executors (it is constructed with a reference to a executor manager, which serves as a factory)
- `inmanta.agent.executor.executor` doesn't know about deploy at all
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
e.g. consider `inmanta.agent.executor.executor` and `inmanta.deploy` packages and the new_agent
- `inmanta.agent.executor.executor` is the interface package for the executor framework
- `inmanta.deploy` is the package containing the scheduler (it has no external interface package)
- `inmanta.deploy` imports `inmanta.agent.executor.executor`
- `inmanta.agent.agent_new` imports both the interface and concrete implementations of both executor and deploy (top level)
- `inmanta.deploy` doesn't import the non-interface parts of `inmanta.agent.executor.executor` because it never constructs executors (it is constructed with a reference to a executor manager, which serves as a factory)
- `inmanta.agent.executor.executor` doesn't know about deploy at all
e.g. consider `inmanta.agent.executor` and `inmanta.deploy` packages and the new_agent
- `inmanta.agent.executor` is the interface package for the executor framework
- `inmanta.deploy` is the package containing the scheduler (it has no external interface package)
- `inmanta.deploy.scheduler` imports `inmanta.agent.executor`
- `inmanta.agent.agent_new` imports both the interface and concrete implementations of both executor and deploy (top level)
- `inmanta.deploy.scheduler` doesn't import the non-interface parts of `inmanta.agent.executor` because it never constructs executors (They are constructed with a reference to a executor manager, which serves as a factory)
- `inmanta.agent.executor` doesn't know about deploy at all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants