Skip to content

[ENH] V1 → V2 API Migration - Tasks#1611

Open
satvshr wants to merge 117 commits intoopenml:mainfrom
satvshr:tasks
Open

[ENH] V1 → V2 API Migration - Tasks#1611
satvshr wants to merge 117 commits intoopenml:mainfrom
satvshr:tasks

Conversation

@satvshr
Copy link
Contributor

@satvshr satvshr commented Jan 9, 2026

Metadata

@codecov-commenter
Copy link

codecov-commenter commented Jan 9, 2026

Codecov Report

❌ Patch coverage is 65.10360% with 320 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.16%. Comparing base (d421b9e) to head (1d3cf95).

Files with missing lines Patch % Lines
openml/_api/clients/http.py 58.41% 89 Missing ⚠️
openml/_api/resources/base/versions.py 24.71% 67 Missing ⚠️
openml/_api/resources/task.py 72.41% 40 Missing ⚠️
openml/_api/setup/backend.py 65.16% 31 Missing ⚠️
openml/_api/resources/base/fallback.py 26.31% 28 Missing ⚠️
openml/_api/resources/base/resources.py 68.75% 15 Missing ⚠️
openml/tasks/task.py 18.75% 13 Missing ⚠️
openml/testing.py 55.55% 12 Missing ⚠️
openml/_api/setup/_utils.py 56.00% 11 Missing ⚠️
openml/_api/setup/builder.py 81.08% 7 Missing ⚠️
... and 3 more
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1611      +/-   ##
==========================================
+ Coverage   52.04%   54.16%   +2.12%     
==========================================
  Files          36       63      +27     
  Lines        4333     5092     +759     
==========================================
+ Hits         2255     2758     +503     
- Misses       2078     2334     +256     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@geetu040 geetu040 mentioned this pull request Jan 9, 2026
25 tasks
@satvshr satvshr marked this pull request as ready for review January 12, 2026 15:29
Copy link
Collaborator

@geetu040 geetu040 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From a high-level review, I noticed a few points that need adjustment:

  • Caching can likely be removed from the SDK, since these concerns should be handled by the base client.
  • I don't see the api_context being used in tasks/functions, so it's not clear to me how the SDK is actually using the new API interface here.
  • Instead of moving entire methods out of tasks/functions.py, it would be better to stick to the goal of minimal SDK changes while enabling v2 support.
  • API calls should be updated at the specific root functions (for example _get_task_description, OpenMLTask._download_split).
  • For listing tasks, please follow the approach discussed in #1575 comment.

@satvshr satvshr marked this pull request as draft January 14, 2026 20:25
@satvshr satvshr changed the title [ENH] Tasks Migration [ENH] V1 → V2 API Migration - Tasks Jan 15, 2026
Copy link
Collaborator

@geetu040 geetu040 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have left some comments, please take a look and make sure the signature of all methods in TasksAPI, TasksV1 and TasksV2 stay same.

@satvshr satvshr marked this pull request as ready for review February 4, 2026 15:57

return pd.DataFrame.from_dict(tasks, orient="index")

def _get_estimation_procedure_list(self) -> builtins.list[dict[str, Any]]:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@geetu040 We already have implemented this function in the estimation_procedure resource, so I think we don't need it to be here, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checked, once we merge your PR we can replace it with the _get_details function yes.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that's the plan

task_type: TaskType | int | None = None,
**kwargs: Any,
) -> pd.DataFrame:
raise NotImplementedError(self._not_supported(method="list"))
Copy link
Contributor

@EmanAbdelhaleem EmanAbdelhaleem Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just use self._not_supported(method="list")

no need for raise NotImplementedError()

assert isinstance(procs, list)
assert len(procs) > 0
assert "id" in procs[0]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to add TestTasksV2 class, and also add v1 and v2 matching tests and fallback tests as mentioned here: #1575 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont need to add TestTasksV2 given those tests are a subset of TestTasksV1. Matching tests are in the shared class.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you still need TestTasksV2 and check if they raise the not implemented error
i think you should use this design then, since there are many common utilities
tests/test_api/test_versions.py

@satvshr satvshr marked this pull request as draft February 4, 2026 17:37
task_type: TaskType | int | None = None,
**kwargs: Any,
) -> pd.DataFrame:
"""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@geetu040
Should we all use the same style or not?
for me, I have splitted this this into 3 functions for more readability and less coupling

  • list()
  • _build_url()
  • _parse_list_xml()

Copy link
Contributor Author

@satvshr satvshr Feb 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need private functions to match each other in terms of nomenclature or functionality as long as we share the same common function names (which we do).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same nomenclature is preferred
I would say you should do this, will make it better anyways

Copy link
Contributor Author

@satvshr satvshr Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do, but I don't necessarily agree. Something similar happened in another project where we were working on 2 algorithms and I suggested something similar but Franz mentioned it is not something that can consistently be maintained across the entire codebase hence does not need change. Given we have 8-9 resources it does not feel fruitful to have people share the same nomenclature for private functions across all PRs, I don't have a strong opinion on this though and I will be making the requested change.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah if your function is lengthy then it's always better to break it into components, otherwise agreed this is not necessary

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah I agree if the function is lengthy, over here (eman's suggestion) we are just removing 15 lines of code and replacing with 1, hence the hesitance. Anyways, I did change it so the pr is ready for review again :D

Copy link
Collaborator

@geetu040 geetu040 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • rename tasks to task, in TestTasksV1, `test_tasks.py just for consistency
  • and other comments from @EmanAbdelhaleem's review

@satvshr satvshr marked this pull request as ready for review February 5, 2026 16:19
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

Successfully merging this pull request may close these issues.

[ENH] V1 → V2 API Migration - tasks

6 participants