[ENH] Simplified Publish API with Automatic Type Recognition

[Omswastik-11]

initially

from openml_sklearn.extension import SklearnExtension
from sklearn.neighbors import KNeighborsClassifier
clf = KNeighborsClassifier(n_neighbors=3)
extension = SklearnExtension()# User instantiates the extension object
knn_flow = extension.model_to_flow(clf) # User manually converts the model (estimator instance) to an OpenMLFlow object
knn_flow.publish()

API

from sklearn.neighbors import KNeighborsClassifier
import openml_sklearn  # Register the extension
import openml

clf = KNeighborsClassifier(n_neighbors=3)

openml.publish(clf)

[fkiraly]

I get this is a draft still, some early comments.

• works for flows only, I would recommend to try for at least two different object types to see the dispatching challenge there.
• do the extension checking inside publish and not in the usage example

[Omswastik-11]

Thanks @fkiraly !!
I checked on flow , datset , task . it is working correctly but in run it is getting some server side issues.

Task 1 failed: https://test.openml.org/api/v1/xml/data/features/1 returned code 274: No features found. Additionally, dataset processed with error - None

[jgyasu]

The PR description is not entirely correct. This is how the interface looks currently:

from openml_sklearn.extension import SklearnExtension
from sklearn.neighbors import KNeighborsClassifier
clf = KNeighborsClassifier(n_neighbors=3)
extension = SklearnExtension()# User instantiates the extension object
knn_flow = extension.model_to_flow(clf) # User manually converts the model (estimator instance) to an OpenMLFlow object
knn_flow.publish()

But I like the idea of a unified publish. I am currently working on a design document for refactoring Extension and this design coincides mine as well, which is a good thing.

[Omswastik-11]

The PR description is not entirely correct. This is how the interface looks currently:

from openml_sklearn.extension import SklearnExtension
from sklearn.neighbors import KNeighborsClassifier
clf = KNeighborsClassifier(n_neighbors=3)
extension = SklearnExtension()# User instantiates the extension object
knn_flow = extension.model_to_flow(clf) # User manually converts the model (estimator instance) to an OpenMLFlow object
knn_flow.publish()

But I like the idea of a unified publish. I am currently working on a design document for refactoring Extension and this design coincides mine as well, which is a good thing.

Thanks for the correction I used the syntax example used in example script . this unified publish was Franz's idea . https://github.com/gc-os-ai/openml-project-dev/issues/8

[codecov-commenter]

Codecov Report

❌ Patch coverage is 28.00000% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.00%. Comparing base (7feb2a3) to head (54d92e2).

Files with missing lines	Patch %	Lines
openml/publish.py	25.00%	18 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1554      +/-   ##
==========================================
- Coverage   52.82%   52.00%   -0.83%     
==========================================
  Files          37       38       +1     
  Lines        4371     4396      +25     
==========================================
- Hits         2309     2286      -23     
- Misses       2062     2110      +48     

☔ 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.

[jgyasu]

I have added some comments. I also feel we should not populate __init__.py with these functions, we can have them in a seperate file and use __init__.py only for imports.

[Copilot]

Pull request overview

Adds a new top-level openml.publish() helper to simplify publishing by automatically recognizing whether the input is an OpenML object or an external estimator handled by an installed extension (e.g., openml-sklearn).

Changes:

• Introduces openml/publish.py with a unified publish(obj, name=..., tags=...) entry point and tag/name merging behavior.
• Exposes publish from openml.__init__ and updates the basic flows/runs tutorial to demonstrate the simplified publishing path.
• Adds unit tests covering publishing an OpenMLBase instance and publishing via the extension registry.

Reviewed changes

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

File	Description
openml/publish.py	Implements the new unified publish API with automatic routing and tag/name handling.
openml/__init__.py	Exports publish at the package top-level and updates __all__.
tests/test_openml/test_openml.py	Adds tests validating publish behavior for OpenML objects and extension-backed models.
examples/Basics/simple_flows_and_runs_tutorial.py	Demonstrates automatic publishing vs manual flow construction in the tutorial.

---

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

[Copilot]

__all__ contains duplicated entries for __version__ and _api_calls. This is likely an accidental copy/paste and can cause confusing docs / from openml import * behavior. Remove the duplicate strings so each symbol appears only once in __all__.

Suggested change

	"__version__",
	"_api_calls",
	"_api_calls",
	"_api_calls",

[Copilot]

This test mocks flow.publish() to return a string and then asserts openml.publish(model, ...) returns that string (and names the variable flow_id). In the real codebase, OpenMLBase.publish() and OpenMLFlow.publish() return self, so openml.publish() should return the published flow object, not an ID. Update the test to reflect the actual return contract (e.g., have flow_mock.publish return flow_mock and assert the returned object is the flow).

[Copilot]

In this tutorial, both “Option A” and “Option B” are executed sequentially, which will upload/publish two flows and then overwrite knn_flow. The later text says it will use the auto-published flow, but the code that follows actually uses the manually created flow. Consider making only one option executable (or use different variables like knn_flow_auto/knn_flow_manual) to avoid double uploads and keep the narrative consistent.

[geetu040]

I am fine with most of the core logic, just have to double-check the extension work and tests.
There are some reviews by Copilot you would want to address.
I've left a comment for discussion.

[geetu040]

What's the reason for adding name and tags as a parameter to publish? I'm not necessarily against it, I would actually prefer it this way, but I am just curious about the motivation or use case behind this. Are there other parameters we can introduce like these? possibly the common attributes between resources that are used in _to_dict to create artifacts for upload.