Skip to content

[ENH] V1 → V2 API Migration - core structure#1576

Open
geetu040 wants to merge 219 commits intoopenml:mainfrom
geetu040:migration
Open

[ENH] V1 → V2 API Migration - core structure#1576
geetu040 wants to merge 219 commits intoopenml:mainfrom
geetu040:migration

Conversation

@geetu040
Copy link
Collaborator

Towards #1575

This PR sets up the core folder and file structure along with base scaffolding for the API v1 → v2 migration.

It includes:

  • Skeleton for the HTTP client, backend, and API context
  • Abstract resource interfaces and versioned stubs (*V1, *V2)
  • Minimal wiring to allow future version switching and fallback support

No functional endpoints are migrated yet. This PR establishes a stable foundation for subsequent migration and refactor work.

@geetu040 geetu040 mentioned this pull request Dec 30, 2025
25 tasks
@codecov-commenter
Copy link

codecov-commenter commented Dec 31, 2025

Codecov Report

❌ Patch coverage is 51.28983% with 321 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.37%. Comparing base (8a5532f) to head (8de99b7).

Files with missing lines Patch % Lines
openml/_api/clients/http.py 23.00% 164 Missing ⚠️
openml/_api/resources/base/versions.py 31.16% 53 Missing ⚠️
openml/_api/resources/base/fallback.py 26.31% 28 Missing ⚠️
openml/_api/setup/builder.py 44.44% 25 Missing ⚠️
openml/_api/setup/backend.py 66.66% 19 Missing ⚠️
openml/_api/resources/base/base.py 57.14% 15 Missing ⚠️
openml/_config.py 80.64% 12 Missing ⚠️
openml/cli.py 0.00% 4 Missing ⚠️
openml/_api/clients/minio.py 85.71% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1576      +/-   ##
==========================================
- Coverage   52.73%   52.37%   -0.37%     
==========================================
  Files          37       61      +24     
  Lines        4399     5035     +636     
==========================================
+ Hits         2320     2637     +317     
- Misses       2079     2398     +319     

☔ 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 requested a review from PGijsbers March 4, 2026 18:01
@geetu040
Copy link
Collaborator Author

geetu040 commented Mar 13, 2026

FYI: @JATAYU000 @satvshr @omkar-334 @rohansen856 @EmanAbdelhaleem

Please sync with this PR. The CI tests should now be passing in all the stacked PRs (except some sporadic failures), since now they are using the local docker services created in the CI which provides endpoints for v2-api as well.

You can run these tests locally as well, with the following steps:

Run docker services locally:

git clone --depth 1 https://github.com/openml/services.git
cd ./services        
chmod -R a+rw ./data
chmod -R a+rw ./logs
docker compose --profile rest-api --profile minio --profile evaluation-engine up -d

Run pytest using the local services (add the env var):

OPENML_USE_LOCAL_SERVICES="true" pytest tests/

Comment on lines +52 to 61
_TEST_SERVERS_LOCAL: dict[APIVersion, dict[str, str | None]] = {
APIVersion.V1: {
"server": "http://localhost:8000/api/v1/xml/",
"apikey": "normaluser",
},
APIVersion.V2: {
"server": "http://localhost:8082/",
"apikey": "AD000000000000000000000000000000",
},
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Presumably they use the same database, is there a reason for using different API keys?

Comment on lines +63 to +71
_SERVERS_REGISTRY: dict[str, dict[APIVersion, dict[str, str | None]]] = {
"production": _PROD_SERVERS,
"test": _TEST_SERVERS_LOCAL
if os.getenv("OPENML_USE_LOCAL_SERVICES") == "true"
else _TEST_SERVERS,
}


def _get_servers(mode: str) -> dict[APIVersion, dict[str, str | None]]:
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it would probably be best to have possible servers in a StrEnum so that the type hints can communicate expected valid values. It's true that users could technically extend the _SERVERS_REGISTERY at runtime and thus more values would be valid but:

  • that's probably incredibly uncommon
  • uses 'internal' functionality (there is a _prefix)
  • the user can still do that, it's just that the type hint wouldn't be accurate if they do

I considered instead type hints with string literals, but considering the amount of call sites below, I think an enum makes more sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants