On February 27, 2022, Ralf Gommers <ralf.gommers@gmail.com> wrote:

I can't remember the details, but there was another problem with it where it wouldn't actually do anything. IIRC a conda maintainer said it was unmaintained or not recommended.

Indeed, looks like the latest recommendations from 2018 and 2019 are to use `python setup.py develop` or `pip install -e .`, as this issue recollected: https://github.com/conda/conda-build/issues/4251

I recommend `python setup.py develop` until it is actually removed. It's not just that you need to use `--no-build-isolation` so easy to shoot yourself in the foot, something like a pip editable install is actually conceptually confused/wrong when you're developing on a project like SciPy. What you want is:1. Create a dev environment (doesn't matter how - conda, virtualenv, standalone Python installer, Nix, Spack, ...) with all dependencies installed.2. Activate the dev env3. Build/install/test on the project.
The conceptual problem that `pip install . -e` has is that, when you're trying to do (3), it "reaches up" and messes with (1). You want to be using commands/tools that can do the build-install-test steps over and over without messing with the environment. python `runtests.py / dev.py / setup.py` all do this right, and `pip install` doesn't. Pip is primarily a package installer, and its use as a pure Python CLI (emphasis on pure Python, where you don't need to care about build isolation, not showing a build log, etc.) is secondary/accidental simply because there isn't a better dedicated tool. For packages with compiled code it's worse than for pure Python code. Unfortunately, most people working on packaging tools only work on pure Python packages, so they don't really see the problems nor the confused mental model.
Cheers,Ralf

Very good point indeed. However, I do understand that passing `--no-deps` to `pip install` would solve this particular problem? In sum, doing something like this:

pip install --no-build-isolation --no-deps -e .

But perhaps I'm unaware of yet another catch. Left a comment summarizing these findings on https://github.com/conda/conda-build/issues/4251#issuecomment-1053460542.

I get the general bitterness towards pip - been following this debate since conda was created (questionable life choices I suppose?) and I'm aware that SciPy/PyData use cases are sometimes an afterthought. But at the same time I acknowledge there have been strands of progress, and for me personally (even if this is not the vision of the project) it has pedagogical value to understand and convey to what extent a new contributor can use "the usual tools" to develop SciPy, avoid deprecated workflows whenever possible, and in sum set boundaries to "SciPy exceptionalism" with proper explanations. Then of course most people will not want their head to explode and say "give me a workflow that works", but as I said, I'm trying to go a bit beyond that, and this thread has been very illuminating in that respect.

Cheers,
Juan Luis