Add CandidatesProtocol

[myrazma]

Prepares #796

• Adds narwhals as a hard dependency for backend-agnostic dataframe operations
• Introduces CandidatesProtocol along with ProductCandidates and TableCandidates classes for representing discrete candidate sets, backed by narwhals lazy frames
• Adds DiscreteParameter.is_finite property and InfiniteSpaceError exception
• Enables validation for extra columns in candidate tables

[Copilot]

Pull request overview

This PR introduces a new candidate-generation abstraction for discrete search spaces, adds Narwhals-based lazy dataframe conversion utilities, and wires in new hard dependencies (narwhals, polars) alongside tests to validate the new candidate classes.

Changes:

• Added CandidatesProtocol plus ProductCandidates (cartesian product + constraints) and TableCandidates (user-provided table) for candidate handling.
• Added Narwhals lazy dataframe conversion helpers (to_lazy_narwhals, from_lazy_narwhals).
• Added dependencies and changelog entries, plus a new test module for candidates.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
baybe/searchspace/candidates.py	New candidate protocol and implementations for product/table candidate generation.
baybe/utils/dataframe.py	Adds Narwhals lazy/native conversion helpers.
baybe/exceptions.py	Adds InfiniteSpaceError for operations requiring finite spaces.
tests/test_candidates.py	New tests for ProductCandidates / TableCandidates.
pyproject.toml	Adds narwhals and polars[pyarrow] as core dependencies.
uv.lock	Updates lockfile to include new dependencies/versions.
CHANGELOG.md	Documents the new dependencies and candidate system additions.

Comments suppressed due to low confidence (1)

tests/test_candidates.py:137

• Pytest parametrizes parameter_names and constraint_names for this test, but test_product_candidates_creation does not accept these arguments. As written, pytest collection will error (“function uses no argument …”). Add the missing arguments to the signature or use indirect parametrization of the parameters/constraints fixtures.

@pytest.mark.parametrize(
    "parameter_names",
    [
        ["Num_disc_1", "Num_disc_2", "Fraction_2"],
        ["Categorical_1", "Num_disc_1"],
        ["Categorical_1", "Categorical_2", "Categorical_1_subset"],
    ],
    ids=["numerical", "mixed", "categorical"],
)
@pytest.mark.parametrize(
    "constraint_names",
    [
        [],
        ["DiscreteSumConstraint"],
        ["DiscreteExcludeConstraint"],
    ],
    ids=["no_constraint", "sum", "exclude"],
)
def test_product_candidates_creation(parameters, constraints):
    """ProductCandidates can be created with valid parameters and constraints."""
    candidates = ProductCandidates(parameters=parameters, constraints=constraints)

---

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

[Scienfitz]

is this PR related to any of the Issues 793 to 798?

[AdrianSosic]

is this PR related to any of the Issues 793 to 798?

Yes, to #796, but only as a preparation step. Will add it to description.

@Scienfitz, @AVHopp: Let me do a first round of polish before you start your review, will save us some unnecessary iterations

[Scienfitz]

please put PRs not ready fort review in draft

[Copilot]

Pull request overview

Copilot reviewed 11 out of 12 changed files in this pull request and generated 6 comments.

[fabianliebig]

@AdrianSosic: Looks pretty good to me, I have a few questions but most of them are really mainly for my understanding and out of curiosity also regarding the upcoming changes. Just because planning and coding is rather different, there are potentially some comments that are obsolete because it's just a preparation PR so feel free to resolve if they don't make much sense to you :)

[AVHopp]

Some first thoughts and questions

[AVHopp]

just to make sure: Previously, we actually allowed extra columns not related to any actual parameter, and we now make this very explicit, right?

[AdrianSosic]

yes, because especially in the context of a dataframe-spanned search space, this is extremely prone to (silent) errors otherwise! Should have done that much earlier, tbh. I'm even considering to turn the default into False now that I think about it. Would strictly be breaking change, but offering guard rails that should have been there from the very beginning 🤔 What do you think?

[AVHopp]

False also feels more natural to me, and while we are on the dev branch we can anyway do whatever we want, so feel free to change it

[AVHopp]

@AdrianSosic I see that the tests are currently failing due to some overflow issue in the serialization tests, is this something new or do we simply need to rebase branches?

[AVHopp]

Please fix failing test (via rebasing if that is the issue ideally), otherwise all gucci :)