Problem
The columnar helpers are exported from mloda.user (the app-facing surface) but not from mloda.provider (the plugin-facing one). Plugin authors are exactly the people who need them.
On main (59661fd), mloda/user/__init__.py re-exports all four from mloda_plugins...python_dict.python_dict_utils:
columnar_to_rows, homogenize_rows, is_columnar, rows_to_columnar
mloda/provider/__init__.py exports none of them.
Why it is the wrong way round
Since 0.9.0, PythonDict's native representation is columnar dict[str, list], so a row-wise FeatureGroup receives a columnar frame in calculate_feature. Pivoting it back to rows is a provider-side concern: it happens inside the plugin, not in application code. The same goes for homogenize_rows, which a source FeatureGroup needs whenever its rows carry optional per-item fields, since 0.9.0 rejects heterogeneous rows instead of union-of-keys normalizing them.
The result is that every row-wise feature group has to reach into the app-facing API to do its own job. In rag_integration (a plugin repo, importing FeatureGroup, FeatureSet, DefaultOptionKeys etc. from mloda.provider), the feature groups now read:
from mloda.provider import FeatureGroup, FeatureSet, DefaultOptionKeys
from mloda.user import columnar_to_rows, homogenize_rows # plugin code importing the user surface
The alternative is importing straight from mloda_plugins.compute_framework.base_implementations.python_dict.python_dict_utils, which is a long internal path with no stability promise.
The compute-frameworks guide points plugin authors at mloda.user for these ("columnar_to_rows, homogenize_rows, is_columnar, and rows_to_columnar are importable from mloda.user"), so the docs and the surface agree with each other, and both point the wrong way for a plugin.
Proposal
Re-export the four helpers from mloda.provider as well, keeping the mloda.user exports (an application unwrapping a run_all result legitimately wants columnar_to_rows too). Then update the compute-frameworks guide to point provider code at mloda.provider.
Context
Found while bumping the rag_integration plugin from mloda 0.8.0 to 0.10.0 (mloda-ai/rag_integration#86). The 0.9.0 columnar change broke all 12 row-wise feature groups there; the fix was mechanical, but the import it forces is semantically backwards.
Problem
The columnar helpers are exported from
mloda.user(the app-facing surface) but not frommloda.provider(the plugin-facing one). Plugin authors are exactly the people who need them.On
main(59661fd),mloda/user/__init__.pyre-exports all four frommloda_plugins...python_dict.python_dict_utils:mloda/provider/__init__.pyexports none of them.Why it is the wrong way round
Since 0.9.0, PythonDict's native representation is columnar
dict[str, list], so a row-wiseFeatureGroupreceives a columnar frame incalculate_feature. Pivoting it back to rows is a provider-side concern: it happens inside the plugin, not in application code. The same goes forhomogenize_rows, which a source FeatureGroup needs whenever its rows carry optional per-item fields, since 0.9.0 rejects heterogeneous rows instead of union-of-keys normalizing them.The result is that every row-wise feature group has to reach into the app-facing API to do its own job. In
rag_integration(a plugin repo, importingFeatureGroup,FeatureSet,DefaultOptionKeysetc. frommloda.provider), the feature groups now read:The alternative is importing straight from
mloda_plugins.compute_framework.base_implementations.python_dict.python_dict_utils, which is a long internal path with no stability promise.The compute-frameworks guide points plugin authors at
mloda.userfor these ("columnar_to_rows,homogenize_rows,is_columnar, androws_to_columnarare importable frommloda.user"), so the docs and the surface agree with each other, and both point the wrong way for a plugin.Proposal
Re-export the four helpers from
mloda.provideras well, keeping themloda.userexports (an application unwrapping arun_allresult legitimately wantscolumnar_to_rowstoo). Then update the compute-frameworks guide to point provider code atmloda.provider.Context
Found while bumping the
rag_integrationplugin from mloda 0.8.0 to 0.10.0 (mloda-ai/rag_integration#86). The 0.9.0 columnar change broke all 12 row-wise feature groups there; the fix was mechanical, but the import it forces is semantically backwards.