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

Split fmu-sumo into separate repositories #215

Closed
perolavsvendsen opened this issue Sep 19, 2023 · 4 comments
Closed

Split fmu-sumo into separate repositories #215

perolavsvendsen opened this issue Sep 19, 2023 · 4 comments
Assignees

Comments

@perolavsvendsen
Copy link
Member

Currently, both the explorer, the uploader and the utilities are in the same repository. This may not scale very well, as seen in e.g. #214. In general, the modules does not share code, but share requirements. While the uploader is depending on packages only available on Unix, the explorer needs to run on Windows.

  • Should this repository be broken up into separate repos?
    • fmu-sumo-explorer (namespace: fmu.sumo.explorer)
    • fmu-sumo-uploader (namespace: fmu.sumo.uploader)
    • fmu-sumo-sim2sumo (namespace: fmu.sumo.sim2sumo) (?)
@AishaAiak
Copy link
Contributor

AishaAiak commented Sep 25, 2023

Refinement 25/09/23

Context:

  • Introducing sim2sumo brought with it requirements which cause problems for some clients, who generally only need the explorer functionality.
  • The uploader and the sim2sumo are not generally used by external users. They are provided to end users through ERT FORWARD_MODELS, in the Komodo context. We have flexibility to change this, as long as the API (FORWARD_MODEL) stays intact.
  • There are issues using e.g. XTgeo on Mac. Solving this is not first priority, as main usage pattern is on Equinor unix through Komodo, secondary pattern is on Windows. However, we can make this easier with conditional dependencies (?)
    • Apparently, there are no issues with XTgeo on Mac? (Ådne has experience with this, to be confirmed.)
  • There are issues using this on Python 3.11 which is ultra-bleeding Python compared current version used in Komodo (3.8). Should we test for 3.11?

Plan:

  • Remove ert requirement from fmu-sumo
  • Move sim2sumo to repo fmu-sumo-sim2sumo (namespace: fmu.sumo.sim2sumo)
  • Add fmu-sumo-sim2sumo to Komodo. Test.
  • Remove ecl2df requirement from fmu-sumo
  • Remove sim2sumo from fmu-sumo
  • Confirm with Dynageo that the issues with installing is OK. See slack thread.
  • Confirm with Webviz
  • Confirm with Webviz-4D

State now: fmu-sumo as it was prior to sim2sumo

  • Split out the uploader into separate repo:
    • Move uploader to repo fmu-sumo-uploader (namespace still fmu.sumo.uploader)
    • In a separate branch on fmu-sumo, remove uploader and sim2sumo.
      • Update and test with Komodo.

State now: Separate repositories

  • Still works as-is in Komodo environment

  • fmu-sumo still contains explorer - but only that.

  • Consider rebuilding/refactoring the uploader (Wait until it is established in its own repo)

Longer term:

  • Clean up repo name? Rename fmu-sumo to fmu-sumo-explorer. May not be necessary.

Key philosophical question: Do we want to have many, small, light repos - or fewer, larger repos?

Requirements

  • Avoid excessive inherited requirements for the explorer
  • Minimal/none disruption to existing usage

Current known users

  • FMU workflows (Komodo)
  • Data consumers (Webviz, etc)
  • Test suites

Other topics

  • XTgeo is a dependency in the explorer. This is causing problems for Mac users. (Explorer is able to return XTgeo RegularSurface objects/instances).

@AishaAiak
Copy link
Contributor

AishaAiak commented Sep 26, 2023

@perolavsvendsen perolavsvendsen changed the title Consider breaking up package into separate repositories Split fmu-sumo into separate repositories Oct 2, 2023
@perolavsvendsen
Copy link
Member Author

perolavsvendsen commented Oct 19, 2023

  • Update existing documentation for fmu-sumo (not correct after repo split) (edit: separate issue created)
  • Create documentation (automatically build) for fmu-sumo-uploader. Mainly for reference? (edit: separate issue created)
  • Create documentation (automatically build) for fmu-sumo-sim2sumo. Mainly for reference? (edit: separate issue created)

Consider if (main) documentation on the front-end should contain the user-facing documentation, or if we want to use ReadTheDocs also for that (or just for the API reference, mainly targeting developers).

@equinor-ruaj
Copy link
Contributor

Repositories split. Closing.

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

No branches or pull requests

5 participants