would be nice to replace this in target with what we do now though. As in, still be able to do make in

it would be a bit weird that in is not the same as inplace anymore though ... more generally see #29296 (comment)

I would rather rename this to dev-setuptools for consistency.

Yeah we could do this, although dev-setuptools would be different to dev-meson in the sense that you need make dev-setuptools each time you change a Cython file.

Keeping make inplace-setuptools you could argue that if some people are still using make in, they can still make in<TAB> so slightly less disruptive. But the number of these people is beween 0 and 1 apparently so 🤷.

I am hoping to look at #29012 again so in the medium term it does not matter that much, so I am fine either way ...

I'm also fine either way, we should not bother too much since we expect to have less and less people installing using setuptools.

+1 for dev-setuptools. Otherwise it's too confusing.

dev-setuptools it is, I also reordered the targets in rough order of importance

I would rather rename this to dev-setuptools for consistency.

Why not keeping this one ? Also, is it enough ? You don't need a git clean ?

Also, since I need to run the commands manually on windows, I find it nice to just have to look into the Makefile to find them

I can keep it if you want, basically you need this if you switch between setuptools and Meson.

If you only use Meson, you do once make dev-meson and then importing sklearn will recompile as needed at import-time. That means, you never have to think do I need to build or not.

Also I find that since scikit-learn is installed as a package that if I want to remove it, pip uninstall scikit-learn -y is something that most people know how to do.

With Meson (or rather ninja) in principle you never need to clean. In the case I wanted to make 100% sure there was not something really fishy happening, I did rm -rf build because that's where pip install -e . will put stuff by default something like build/cp312 for a Python 3.12 install.

Actually this is broken (using meson-python 0.16.0):

$ make dev
...
$ rm -rf build  # alternatively: git clean -xdf
$ python -c "import sklearn; sklearn.show_versions()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1138, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1078, in _find_spec
  File "/Users/ogrisel/miniforge3/envs/dev/lib/python3.11/site-packages/_scikit_learn_editable_loader.py", line 310, in find_spec
    tree = self._rebuild()
           ^^^^^^^^^^^^^^^
  File "/Users/ogrisel/miniforge3/envs/dev/lib/python3.11/site-packages/_scikit_learn_editable_loader.py", line 338, in _rebuild
    if self._work_to_do(env):
       ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ogrisel/miniforge3/envs/dev/lib/python3.11/site-packages/_scikit_learn_editable_loader.py", line 325, in _work_to_do
    p = subprocess.run(dry_run_build_cmd, cwd=self._build_path, env=env, capture_output=True)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ogrisel/miniforge3/envs/dev/lib/python3.11/subprocess.py", line 548, in run
    with Popen(*popenargs, **kwargs) as process:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ogrisel/miniforge3/envs/dev/lib/python3.11/subprocess.py", line 1026, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/Users/ogrisel/miniforge3/envs/dev/lib/python3.11/subprocess.py", line 1950, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/Users/ogrisel/code/scikit-learn/build/cp311'

Ideally one would want meson-python to tolerate that and rebuild the missing build directory, no?

🤔 I probably was not clear in my previous comment before, here is what I wanted to say:

• if you are only working with Meson, you do make dev-meson once and then use scikit-
  learn since importing will retrigger compilation. I guess people who have switched to Meson probably never had to think much about "cleaning", it just works
• pip uninstall -y scikit-learn is the way to "clean" Meson, in case you want to switch to setuptools. I am guessing most people don't have to do this unless you switch to an old PR.
• every once in a while, like every month, I am looking at a fishy behaviour, and just because I am paranoid I do rm -rf build. This is clearly not needed and also not a good idea to do in general because you may have other build there of scikit-learn built for other other environments and Python versions.

All in all if you insist you want a make clean and make clean-meson I would stick with the previous behaviour of only doing pip uninstall -y scikit-learn

If you want an example of a fishy behaviour, I was looking why somehow we lost pytest assertion rewriting in Meson (i.e. pytest is not showing the value of values on each side of the assertion see #29253 (comment)), so I was switching between Meson and setuptools, and I did not want to take any risks so I did rm -rf build.

I think it's helpful to have an official way to handle the cleaning of a dev build that does not result in one of the broken states I posted above.

Because indeed some people are paranoid and will attempt to do a "clean" operation manually from time to time (even if it's useless, just in case) and end up in the same state as I did.

Because indeed some people are paranoid and will attempt to do a "clean" operation manually from time to time

I'm one of those guys and I'm pretty sure it got me out of a very broken state sometimes :)
Anyway, even if it trivial, I'd rather have the shortcut, and I like being able to see all the necessary commands explicitly at one place.

OK is my last commit good enough or you want an additional clean-paranoid target that does rm -rf build (on top of clean that does pip uninstall -y scikit-learn 😉)?

good enough for me