I don't think this PR belongs here.

If you're trying to update your local branch, refer to https://scikit-learn.org/dev/developers/contributing.html#how-to-contribute

This isn't a mistake, the branch https://github.com/scikit-learn/scikit-learn/tree/feature/engine-api has been moved from @ogrisel fork to scikit-learn main repo but I lost permissions to push on it in the process.

This PR is adding more than 46k lines of code, no way we can review it. For feature branches, it's easier for the champion of the branch (I guess in this case @ogrisel ) to merge main into that branch directly every now and then, like the other branches we've had.

We haven't pulled main for several months because the project was slowed down, so now that I want to catch up there's 46k diff. I need the test pipelines to run so I can finalize the work.

The review of the actual diff from feature/engine-api to main is expected to take place in #25535 .

Thanks @adrinjalali

Opened the PR for the CI to run, but I would rather not have this PR merged and once tests are okay, @ogrisel can merge main into the feature branch.

@betatim could also merge this branch.

I had a quick look because the 46K lines seem strange but it looks legit.
I did not think that we could have that many changes but it seems that between the isort and lock files, we can get there.

What is the downside to using a PR based workflow (that targets the feature branch) to work around permission issues like Franck has? Maybe adding to the PR description that this is a work around for permission issues and other context would be useful for the future.

I think we need a way for people like Franck to make progress on work even when all the core devs related to the feature branch are on holiday (for several weeks). And even when I'm not on holiday it is nice for Franck to be able to do stuff, instead of being blocked by when I/Olivier have time to get around to something. Maybe we can work out a way to achieve that.

(I've not yet had time to look through all my GH notifications since going on holiday)

At the pace we've been working on this branch lately it's not too much of an issue. For now my work on this branch is completed (fully tested with soda-inria/sklearn-numba-dpex#114 ) could you synchronize it with engine/feature-api please ? (merge or manually pull on engine/feature-api, as you wish)

There were only a few minor conflicts in kmeans (with recent changes regarding sample_weight) + ruff compliance to catch on.

What is the downside to using a PR based workflow (that targets the feature branch) to work around permission issues like Franck has? Maybe adding to the PR description that this is a work around for permission issues and other context would be useful for the future.

The downside is that this came out of nowhere, with no context given on the PR description. So I genuinely thought it's a mistake / spam PR. And it's rebasing and including like 180 PRs or more. There's no way to review this.

I think we need a way for people like Franck to make progress on work even when all the core devs related to the feature branch are on holiday (for several weeks). And even when I'm not on holiday it is nice for Franck to be able to do stuff, instead of being blocked by when I/Olivier have time to get around to something. Maybe we can work out a way to achieve that.

When I worked on SLEP6, other people were working on it as well, but I made sure the branch is up to date whenever it needed to be. That's what I'd expect from you (@betatim ) or @ogrisel to do as well. And you not doing it in time doesn't block people from working on the feature since everybody can merge with main and work on their corresponding feature while you manage to update the upstream branch. So letting the champions do this isn't really a blocker.

But sure, if you wanna merge this into the feature branch go ahead. However, it would be nice if one of you handles these cases.

Merging this for now.

I agree that we need more context in the original message if we want to use this strategy in the future.