ERT repository - content and structure

[markusdregi]

Context
Earlier this year we moved libres back into the ERT repository to ease ERT development and avoid the need for synchronised work in branches over multiple repositories. In addition, we created a new module in the root repository named ert. We should create and document a clear direction for how to proceed maturing the structure of the repository and decide whether we should move more repositories into ERT.

Related repositories
The following repositories lives in the very close proximity of ERT:

• ert-storage - to store the ERT datamodel,
• semeio - a collection of forward model and workflow jobs,
• webviz-ert - a visualisation tool that can run on top of ert-storage.

For each of the above repositories we should decide on whether it would be beneficial to move the repository into ERT or keep it as a separate repository.

Module structure
Currently the following Python modules lives within the ERT repository: ert, ert3, ert3_examples, ert_gui, ert_logging, ert_shared, job_runner, and res. The responsibilities of the modules and the granularities of said responsibilities are unclean and overlapping in some cases. We should agree upon a direction for how we would like to structure the content over the different modules. Do we want to keep them all? Have a single root module ERT? Or something in-between?

Import strategy
The different modules above have very different approaches to imports. Some practice that importing the root module shout be sufficient to get access to all of the relevant functionality (ie. import ert3), while other modules depend heavily on importing the specific content needed (from ert_shared.ide.keywords.advanced_keywords import AdvancedKeywords).

We should establish a uniform approach to how the content of modules are made available.

[pinkwah]

I reckon that before we start integrating other projects into ERT, we'll need to sort out the unit testing time. For example, the ERT Storage tests are quick, taking only a few minutes to complete. Compare this to ERT which takes upward of an hour. Thus, if ERT Storage is part of the ERT repository, any change to ERT Storage will trigger a run for the entire system.

I think having modularised testing is very important if we are to do a monorepo. I've started a separate discussion in #2336

[dafeda]

I propose we create an ert2 directory that includes ert_logging, ert_data, ert_gui, docs, ert_shared and share.

The ert3 directory "should" contain ert3_examples.

Not sure what the goal of the ert directory is.

I propose that the ert directory contains everything related to what we today call ert2, and that we rename ert3 to for example ertCloud.

This will allow us to evolve both todays ert and ertCloud separately using SemVer.

[oyvindeide]

I propose that the ert directory contains everything related to what we today call ert2, and that we rename ert3 to for example ertCloud.

This will allow us to evolve both todays ert and ertCloud separately using SemVer.

I like the idea of introducing semver in ert, and not tying us to the ert3 namespace (while development is not effected in any way), while there have not historically been semver in ert, now that we have included libres and are actively changing the api, all of a sudden it makes more sense in my opinion.