Typed objects block model by denis-simo · Pull Request #216 · SeequentEvo/evo-python-sdk

denis-simo · 2026-02-19T23:47:19Z

This PR brings block models under the same typed object envolope as recently added objects.

Key parts of this pull requets:

BLock models are now an OPTIONAL dependency for objects. We want to have a single point of entry and block models on evo are not just references from the perspective of the user - they are actual block models that the user expects to interact with. If the user does not install block models, they can interact with block model metadata handling the current dependency in a similar way to pandas and numpy. Evo-sdk user will get the whole package, sneaky developer who only cares about very thin set of changes - can get evo-objects with cut down dependencies.
Block model dependencies were adjusted so that by default it can be used just to parse metadata. Interaction with data is now an optional dependency, this way for basic services that don't care about interacting with evo-data and that user evo-objects there is no extra dependency added.
Block models support dataframe conversions, pretty printing via widgets, report creation, and automated mapping/creation from object_from_reference/path.
I have shared typed definitions in Common, without going as far as adding shared functionality that relies on numpy to avoid new depenency on common.
Block model in objects acts as a wrapper for a fully featured typed objects in evo-block models that can exist by itself.
I have not added any converters to and from block model and 3D grid... but it is not that hard as interfaces are similar though not identical and because the objects are different enough - we do not want to have more shared interfaces at this stage other than common base blocks.
OCTREE and FULLY SUBBLOCKED modes support was left out for now (via typed Objects) - PR is large already

This is a meaninful update, so I have bumped up the versions. If we want to release this, I can write up the changelong now as well, though there is one more PR to come after this for Kriging compute.

Checklist

I have read the contributing guide and the code of conduct

…ion and more convenient interactions as part of notebooks by novice python users (geologists). Updated some of the method names to match pandas/tables syntax.

# Conflicts: # packages/evo-widgets/docs/examples/displaying-typed-objects.ipynb # packages/evo-widgets/src/evo/widgets/formatters.py

…iogram use.

…jects-variogram # Conflicts: # code-samples/geoscience-objects/README.md # code-samples/geoscience-objects/simplified-object-interactions/simplified-object-interactions.ipynb # packages/evo-objects/docs/examples/typed-objects.ipynb # packages/evo-objects/src/evo/objects/typed/__init__.py # packages/evo-objects/src/evo/objects/typed/base.py # packages/evo-widgets/README.md # packages/evo-widgets/docs/examples/displaying-typed-objects.ipynb # packages/evo-widgets/pyproject.toml # packages/evo-widgets/src/evo/widgets/__init__.py # packages/evo-widgets/src/evo/widgets/formatters.py # packages/evo-widgets/src/evo/widgets/urls.py # packages/evo-widgets/tests/test_formatters.py # packages/evo-widgets/tests/test_urls.py # uv.lock

…ped-objects-block-model # Conflicts: # code-samples/geoscience-objects/running-kriging-compute/running-kriging-compute.ipynb

…jects-block-model # Conflicts: # code-samples/geoscience-objects/running-kriging-compute/running-kriging-compute.ipynb # packages/evo-widgets/src/evo/widgets/__init__.py # packages/evo-widgets/src/evo/widgets/formatters.py # packages/evo-widgets/tests/test_formatters.py

RyanMillerSeequent

Have only looked at packages/evo-objects and everything LGTM there.

wordsworthc · 2026-02-23T01:06:50Z

packages/evo-blockmodels/src/evo/blockmodels/typed/_utils.py

+def pyarrow_to_dataframe(table: "pa.Table") -> "pd.DataFrame":
+    """Convert a PyArrow Table to a pandas DataFrame.
+
+    :param table: The PyArrow Table to convert.
+    :return: A pandas DataFrame.
+    :raises ImportError: If pyarrow or pandas is not installed.
+    """
+    _check_pyarrow_available()
+    _check_pandas_available()
+    return table.to_pandas()


In general I prefer not to use string-literal annotations. In this case I think either including from __future__ import annotations, or conditionally defining the implementation (consistent with evo.objects.DownloadedObject.download_table(...), for example) would be acceptable.

wordsworthc · 2026-02-23T01:10:20Z

packages/evo-blockmodels/src/evo/blockmodels/typed/_utils.py

+if TYPE_CHECKING:
+    import pandas as pd
+    import pyarrow as pa


It looks like pandas and pyarrow are always required by typed block models, so it doesn't make sense to defer annotation here

wordsworthc · 2026-02-23T01:10:44Z

packages/evo-blockmodels/src/evo/blockmodels/typed/_utils.py

+def _check_pyarrow_available() -> None:
+    """Check if pyarrow is available, raise ImportError with helpful message if not."""
+    try:
+        import pyarrow  # noqa: F401
+    except ImportError as e:
+        raise ImportError(
+            "pyarrow is required for this operation. Install it with: pip install evo-blockmodels[pyarrow]"
+        ) from e
+
+
+def _check_pandas_available() -> None:
+    """Check if pandas is available, raise ImportError with helpful message if not."""
+    try:
+        import pandas  # noqa: F401
+    except ImportError as e:
+        raise ImportError(
+            "pandas is required for this operation. Install it with: pip install evo-blockmodels[pyarrow]"
+        ) from e


Similarly, these checks seem redundant

wordsworthc · 2026-02-23T01:18:32Z

packages/evo-blockmodels/src/evo/blockmodels/typed/_utils.py

+        ) from e
+
+
+def pyarrow_to_dataframe(table: "pa.Table") -> "pd.DataFrame":


In general I prefer not to use string literal annotations, seeing as from __future__ import annotations was added in python 3.7, and starting with python 3.14, annotations are lazily evaluated by default.

wordsworthc · 2026-02-23T01:24:35Z

packages/evo-blockmodels/src/evo/blockmodels/typed/types.py

+These types are re-exported from evo.common.typed for backward compatibility.
+"""
+
+from evo.common.typed import BoundingBox, Point3, Size3d, Size3i


Now that types have been refactored into the common module I think it would be worth updating the relevant imports wherever they are used. I don't see any reason to keep this module around

wordsworthc · 2026-02-23T01:33:29Z

packages/evo-blockmodels/pyproject.toml


 [project.optional-dependencies]
-pyarrow = ["pyarrow>=19.0.0"]
+pyarrow = ["pyarrow>=19.0.0", "pandas>=2.0.0"]


I'm wondering if we should rename this optional dependency group to utils for consistency with evo-objects

wordsworthc · 2026-02-23T01:36:44Z

packages/evo-blockmodels/src/evo/blockmodels/typed/__init__.py

+    ReportResult,
+    ReportSpecificationData,
+)
+from .types import BoundingBox, Point3, Size3d, Size3i


Even though these are now provided by evo.common.typed, I think it is still useful to export them from this namespace for convenience. Perhaps import them from evo.common.typed though

wordsworthc · 2026-02-23T01:41:01Z

packages/evo-blockmodels/src/evo/blockmodels/typed/report.py

+if TYPE_CHECKING:
+    from ..client import BlockModelAPIClient
+    from ..endpoints.models import (
+        ReportResult as APIReportResult,
+    )
+    from ..endpoints.models import (
+        ReportSpecificationWithJobUrl,
+        ReportSpecificationWithLastRunInfo,
+    )


In general I think it is cleaner to avoid if TYPE_CHECKING: guards unless they are absolutely necessary.

Suggested change

if TYPE_CHECKING:

from ..client import BlockModelAPIClient

from ..endpoints.models import (

ReportResult as APIReportResult,

)

from ..endpoints.models import (

ReportSpecificationWithJobUrl,

ReportSpecificationWithLastRunInfo,

)

from ..client import BlockModelAPIClient

from ..endpoints.models import ReportResult as APIReportResult

from ..endpoints.models import ReportSpecificationWithJobUrl, ReportSpecificationWithLastRunInfo

Also, the existing convention for using generated models is to import them as:

Suggested change

if TYPE_CHECKING:

from ..client import BlockModelAPIClient

from ..endpoints.models import (

ReportResult as APIReportResult,

)

from ..endpoints.models import (

ReportSpecificationWithJobUrl,

ReportSpecificationWithLastRunInfo,

)

from ..client import BlockModelAPIClient

from ..endpoints import models

Then reference them like so:

def _from_api_result(cls, result: models.ReportResult) -> ReportResult:

This eliminates the need for aliasing and makes it difficult to accidentally export generated models.

wordsworthc · 2026-02-23T01:56:25Z

packages/evo-objects/src/evo/objects/typed/block_model_ref.py

+def _require_blockmodels(operation: str = "This operation") -> None:
+    """Raise ImportError if evo-blockmodels is not installed."""
+    if not _BLOCKMODELS_AVAILABLE:
+        raise ImportError(
+            f"{operation} requires the 'evo-blockmodels' package. Install it with: pip install evo-objects[blockmodels]"
+        )


I would guard the method definitions where evo.blockmodels is used, rather than raise an exception.

Do consider whether you expect any of the types in this module to be used without evo-blockmodels installed.

wordsworthc · 2026-02-23T02:00:50Z

packages/evo-sdk-common/src/evo/common/__init__.py

+from .typed import BoundingBox as BoundingBox
+from .typed import Point3 as Point3
+from .typed import Size3d as Size3d
+from .typed import Size3i as Size3i


Why are these aliased?

Suggested change

from .typed import BoundingBox as BoundingBox

from .typed import Point3 as Point3

from .typed import Size3d as Size3d

from .typed import Size3i as Size3i

from .typed import BoundingBox, Point3, Size3d, Size3i

denis-simo added 19 commits February 17, 2026 08:04

Added Quality of life additions to typed objects for better presentat…

8c940b9

…ion and more convenient interactions as part of notebooks by novice python users (geologists). Updated some of the method names to match pandas/tables syntax.

Added variogram typed object.

cb338dd

Updates to incorporate a new package into the CI/CD process.

3951d85

Fixed up linting

93c9b50

Merge branch 'typed-objects-qol-signed' into typed-objects-variogram

f767bf0

# Conflicts: # packages/evo-widgets/docs/examples/displaying-typed-objects.ipynb # packages/evo-widgets/src/evo/widgets/formatters.py

Fixed up linting formatting and added a code sample that includes var…

50b01f5

…iogram use.

Added block model typed objects alongside with the block model reports.

196b0bf

Linting that was missed.

1a63ba1

Stripped out the outputs .

b0e259d

Stripped out the outputs .

b8d8169

Fixed up bad merge.

77e2b81

Linting

6620a06

Fixed up local import that I missed.

288b7d6

Code review feedback.

8009509

Code review feedback.

262e46c

Merge remote-tracking branch 'origin/typed-objects-variogram' into ty…

0e99708

…ped-objects-block-model # Conflicts: # code-samples/geoscience-objects/running-kriging-compute/running-kriging-compute.ipynb

Removed outputs via uv nbstripout

861ebbc

denis-simo requested review from a team as code owners February 19, 2026 23:47

Verbal code review feedback after in person review.

cd9d4ea

denis-simo requested a review from a team as a code owner February 22, 2026 20:08

RyanMillerSeequent approved these changes Feb 22, 2026

View reviewed changes

wordsworthc reviewed Feb 23, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

Typed objects block model#216

Typed objects block model#216
denis-simo wants to merge 20 commits intoSeequentEvo:mainfrom
BenLewis-Seequent:typed-objects-block-model

denis-simo commented Feb 19, 2026 •

edited

Loading

Uh oh!

RyanMillerSeequent left a comment

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

wordsworthc Feb 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		) from e


		def pyarrow_to_dataframe(table: "pa.Table") -> "pd.DataFrame":

Comments

Conversation

denis-simo commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

RyanMillerSeequent left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

denis-simo commented Feb 19, 2026 •

edited

Loading