fix: local TabPFN import drift and declare SciPy explicitly

[thomasATbayer]

Fix local TabPFN import drift and declare SciPy explicitly

Summary

This PR fixes the local TabPFN import failure reported in issue #64.

The failure was caused by stale local TabPFN installs drifting away from the supported MotherML dependency set.

Important: this PR does not downgrade scikit-learn. MotherML continues to use the sklearn 1.9 stack already exercised in CI. The actual fix is to align the TabPFN extra and local environments with that tested stack.

This PR also fixes a packaging problem that was part of the confusion: MotherML imports SciPy directly, but SciPy was not clearly represented as an explicit first-class dependency in the supported dependency story for this change. The PR now makes SciPy part of the dependency fix explicitly rather than leaving it implicit via transitive installs.

What changed

1. Restored the supported scikit-learn range that matches the working CI environment.
2. Added explicit base scipy dependency because MotherML imports SciPy directly in multiple modules.
3. Kept scikit-learn>=1.9.0,<1.10 unchanged as the supported range.
4. Updated the tabpfn extra from 8.0.8 to 8.2.0 so it matches the tested sklearn 1.9 environment.
5. Removed the legacy TabPFN special-case import handling that was only there for older broken version combinations.
6. Regenerated uv.lock to keep the resolved environment in sync.

Why

• The supported stack should match what CI actually tests.
• The supported stack remains sklearn 1.9; the local breakage was from an outdated TabPFN install, not from sklearn itself.
• Local pip installs should not fail because an older unrelated TabPFN wheel is hanging around.
• MotherML should declare SciPy explicitly instead of relying on transitive installation through other packages.
• Making SciPy explicit improves reproducibility for both local installs and published package consumers.

Validation

Validated with a fresh supported environment:

uv run --extra tabpfn python -c "import tabpfn; print(tabpfn.__version__)"

Observed result:

tabpfn import ok 8.2.0

Resolved environment remains on sklearn 1.9.

Impact

• Fixes local TabPFN import failures caused by environment drift.
• Keeps MotherML on the sklearn 1.9 dependency stack already proven in CI.
• Aligns the TabPFN extra with that tested stack.
• Makes SciPy an explicit supported dependency instead of an accidental transitive one.
• Keeps release behavior as a patch release because this is a bug fix.

[Copilot]

Pull request overview

This PR addresses local TabPFN import failures by aligning declared dependencies/extras with the scikit-learn 1.9 stack exercised in CI, and by tightening optional-dependency handling in the TabPFN model integration.

Changes:

• Add an explicit base dependency on scipy and keep the supported scikit-learn>=1.9.0,<1.10 range.
• Bump the tabpfn optional extra to 8.2.0 to match the supported stack.
• Refresh uv.lock to reflect the updated dependency resolution.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
pyproject.toml	Adds scipy to base deps and bumps the tabpfn extra to 8.2.0.
src/mother/ml/models/m_tabpfn.py	Adds optional-dependency import guarding for TabPFN imports (with a noted gap around torch/ImportError handling).
uv.lock	Regenerates the lockfile to match updated dependency resolution (including TabPFN bump and explicit SciPy).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/mother/ml/models/m_tabpfn.py:71

• Raising ExtrasDependencyImportError here will currently suggest installing mother[tabpfn] / uv add 'mother[tabpfn]', but the distribution name is mother-ml (README.md explicitly warns there is a different mother package on PyPI). This error message is likely to send users to the wrong package; consider updating ExtrasDependencyImportError to recommend pip install 'mother-ml[tabpfn]' and the appropriate uv add mother-ml --extra tabpfn / uv sync --extra tabpfn command.

except ImportError as import_error:
    raise ExtrasDependencyImportError("tabpfn", import_error) from import_error

src/mother/ml/models/m_tabpfn.py:71

• The module-level import wrapper catches all ImportError and re-raises ExtrasDependencyImportError, which can mislead users when TabPFN is installed but incompatible (e.g., sklearn symbol moved) or when TabPFN itself raises an ImportError internally. Consider only wrapping missing-module cases (ModuleNotFoundError) and letting other ImportError exceptions surface unchanged so the underlying compatibility error is not masked.

This issue also appears on line 70 of the same file.

    from tabpfn import TabPFNClassifier, TabPFNRegressor
    from tabpfn.constants import ModelVersion
    from tabpfn.regressor import FullOutputDict
except ImportError as import_error:
    raise ExtrasDependencyImportError("tabpfn", import_error) from import_error

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/mother/ml/models/m_tabpfn.py:74

• The reported TabPFN drift failure (e.g. ImportError: cannot import name '_is_pandas_df' from sklearn.utils.validation) is an ImportError, not a ModuleNotFoundError. With the current exception handling, that incompatibility won’t be wrapped in ExtrasDependencyImportError, so users still get a cryptic traceback instead of the actionable “install mother-ml[tabpfn]” guidance.

except ModuleNotFoundError as import_error:
    missing_root = (getattr(import_error, "name", "") or "").split(".")[0]
    if missing_root in {"tabpfn", "torch"}:
        raise ExtrasDependencyImportError("tabpfn", import_error) from import_error
    raise

src/mother/errors.py:14

• The suggested uv sync --extra ... command is generally not applicable to package consumers (it enables extras of the current project), and uv add mother-ml --extra ... is primarily a pyproject-editing workflow. For an import-time extras error, it’s more reliable to suggest uv pip install 'mother-ml[extra]' (and optionally uv add 'mother-ml[extra]').

            + f"$ {style}pip install 'mother-ml[{extras_type}]'{Style.RESET_ALL} or\n"
            + f"$ {style}uv add mother-ml --extra {extras_type}{Style.RESET_ALL} or\n"
            + f"$ {style}uv sync --extra {extras_type}{Style.RESET_ALL}"

test/unit/test_errors.py:12

• This test currently asserts the old uv guidance strings (uv add mother-ml --extra ... / uv sync --extra ...). If the error message is updated to use uv pip install 'mother-ml[extra]' and uv add 'mother-ml[extra]', update the expected substrings accordingly so the test continues to validate the user-facing instructions.

    assert "pip install 'mother-ml[example]'" in str(error)
    assert "uv add mother-ml --extra example" in str(error)
    assert "uv sync --extra example" in str(error)

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.