Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support non-setuptools-backed editable setup #39

Open
uranusjr opened this issue Sep 7, 2018 · 5 comments
Open

Support non-setuptools-backed editable setup #39

uranusjr opened this issue Sep 7, 2018 · 5 comments
Labels

Comments

@uranusjr
Copy link
Member

uranusjr commented Sep 7, 2018

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
Copy link
Member

How about relying on pip...

@uranusjr
Copy link
Member Author

uranusjr commented Sep 7, 2018

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

@techalchemy
Copy link
Member

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
Copy link
Member Author

uranusjr commented Sep 7, 2018

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants