pip 19.1 and develop mode (with pyproject.toml - build-backend present)

So I get now pip is PEP compliant, and the reasons why it was done.

However, this now breaks peoples workflow without any sane workaround (the only one to work is to remove pyproject.toml file before install and put it back afterwards), I consider it as a PEP oversight to not specify that it does not apply for editable installs.

PEP-517/8 on purpose did not want to cover editable installs, considering something to be addressed down the line (there’s some discussion on the topic upstream, but that’s ages away from reality). As such I would argue PEP-517/PEP-518 no longer applies when editable install mode is enabled. It’s the build frontend dependent on how this case is handled.

We have two options now:

• In develop mode, pip should fallback to the old system, maintain the status quo until we figure out how to support editable installs in the new world.
• Alternatively, provide a flag that triggers the old build system independent of the presence/content of the pyproject.toml.

Note this now breaks a lot of dependent systems (pipenv, tox, poetry, etc).

[gaborbernat]

Also, the next pip release isn’t for 3 months, so there’s no huge rush. Let’s think things through and make sure we have a good solution before rushing into someone writing a PR.

This breaks a lot of CIs and workflows. Notably mypy, tox, virtualenv (but a lot-lot more within my workplace). I consider this to be a bug-fix request, so waiting for three months feels to me not the right way to go.

[pganssle]

I have proposed discussing this at the Packaging Mini-summit, to the extent that “likes” are considered votes, liking it will help get it prioritized.

Either way, maybe we can get the new standard jump-started at PyCon next week? I’m thinking an open space to flesh out ideas among people interested would be good, if there’s time.