Support non-setuptools-backed editable setup

[uranusjr]

Currently editables are installed by running setup.py develop, which means it needs to be setuptools-based. I was looking into how flit sets up an editable installation and realise this can be replaced by a *.dist-info and a pth file. It could be interesting to look into.

A problem with alternative build systems is that there needs to be a way to understand what exactly needs to be installed. setuptools has setup.py, but other systems can define things differently. This would probably require a spec change in either Pipfile (to specify what backend to use for an editable), or an extension in PEP 518 (so a build system can define how its edditables are should be installed). It would be a good topic to ponder on in the long run.

• dist-info is specified in PEP 376

[techalchemy]

How about relying on pip...

[uranusjr]

AFIK pip does not support non-setuptools based editable install either. Also since I’m already thinking about breaking away from pip anyway…

[techalchemy]

Literally just had this convo on an issue. Of course it does. You literally can’t actually build editable installs without first installing the specified build tools. That was the point of the PEP.

Whether you want to break from pips internals or not it seems silly to think you can build a thing that knows how every possible build system would work. The whole point is you won’t have to. The build system itself supplies an sdist or a wheel. Are you saying we can read dependencies from those?

[uranusjr]

Build a flit project and try to pip install -e it yourself. It does not work. Period.

pip install -e only works for setuptools-based projects. The project may have build tools declaration (PEP 518), but to be editable-installed, the build tool needs to be setuptools. This is a fact.

[techalchemy]

The challenge of editable installs has basically nothing to do with how you link source code into a virtualenv which is why we are talking past each other. You’re talking about putting a path file in a virtualenv which is fine, but also not that important. The real distinguishing feature here is how the code gets turned into a distributable package, because that is how dependencies are computed.

I’ve spent a good amount of time on this today and I wound up at the same conclusion as the folks in the pip issue— and it’s the same exact approach you are already taking which is why I don’t see the problem. The various build systems all have defined hooks for building wheels. You already know what to with a wheel. For things that are not defined in this way, yes, we will need to fall back to setuptools. That’s not surprising given that it was the default for many years and most projects won’t make any changes.

It’s ok to use another persons libraries to do the things they are built for, e.g. pip and setuptools. Both of those are bundled with python now, even, so it really feels like they are probably sane fallbacks and we don’t have to over engineer this. Otherwise we will wind up being unable to install basic python sdists........