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

[gaborbernat]

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

[pfmoore]

While I'm not trying to apportion blame here, it should be noted that a much simpler fix would be to simply delete pyproject.toml. The reason this isn't possible appears to be because projects like black chose to use that file for their general configuration, which is arguably allowed by PEP 518 (it depends on how you define "build tool", basically) but might be considered a bit premature, when the intended use of that file (PEPs 517 and 518 were still in development).

We need to find a way forward, and not look back at how we got here, but it might be worth someone looking at the possibility of black adding support for configuraion in setup.cfg. I don't know if other tools have pyproject.toml-only configuration - if the problem is significantly more widespread than just black, then this may not be a practical solution.

[gaborbernat]

@pfmoore it's not important how we got here or who is to blame.

The workflow that this breaks is the following: you want to distribute your code as PEP-517/518. And you're testing with pure PEP-517/518 in your CI/tox. However, while developing the codebase it's helpful to install the code in developer mode (to avoid needing to reinstall the package after every code-change to run your tests). In such case, you do want to install the code in editable mode (but also to keep the pyprojec.toml). Deleting the file is not possible in this case. Specifying no pep 517 builds also doesn't work.

[pfmoore]

Ah, OK. There's so many cases being discussed across various issues that I'd missed that this was talking about a different situation¹. Sorry.

That's definitely a fair comment then - although it's probably worth being clear when documenting this that you would be doing your development with what is essentially a completely different build system than the one you're going to deploy with. As an example, console script wrappers are handled in a completely different way depending on whether you use the legacy direct install method or the PEP 517 install via wheel method.

¹ It might be worthwhile for someone to collect together the various use cases we're seeing reported here and document them, as a starting point for the inevitable "how to extend PEP 517 to support editable mode" discussion. If nothing else, this whole debate makes it clear that the need for a standard covering editable mode isn't something we can put off too long.

[gaborbernat]

@pfmoore that's okay though, editable mode always was a close enough approximation; the non-editable test suits are the ones that confirm 100% the code is good. For example, if one would load resources they can behave differently. But this is already the case. As such needing to pass some flags is alright, however, for now, there's no way to do this. Can we get a fix? --really-ignore-pep517-for-develop-mode is fine by me.

[mattaustin]

Specifying no pep 517 worked for me. For anyone who hit this when using tox, adding a custom install_command line to tox.ini is my current workaround (I only have pyproject.toml for setting the line length for black).

[testenv]
install_command =
    python -m pip install --no-use-pep517 {opts} {packages}

[gaborbernat]

That's a different problem, as you don't have build-backend and requires specified.

[cjerdonek]

@gaborbernat Can you do something like have a simple wrapper script you use when developing locally that moves the file prior to installing in editable mode? Or copying the pyproject.toml file into place when running in CI, etc? I'm not sure the exact situation, but it seems like you'd have a fair amount of flexibility in coming up with a workflow.

[gaborbernat]

Moving around the files is a really bad workaround and would generate a lot more trouble. This now breaks tox for example. tox it's no longer able to create a develop environment.

While moving the pyproject.toml out and back would workaround the issue (in a scary horrible way), it would break parallel mode. Imagine if you want to run 5 tox environments in parallel, 4 of them use PEP 517/518 and one wants an editable install (for example is the only way cython code coverage can be done). Again feels to me like a bad place to be, now one would need some lock to hold why altering the work tree, just to get an editable install through. On this point, I either downgrade to pip < 19.1, or use python setup.py develop... I would really prefer a true PEP-517/PEP-518 disable behind an obscure flag. Wrapper scripts at that point can pass through that, rather than altering the source directory in-place.

[cjerdonek]

Imagine if you want to run 5 tox environments in parallel, 4 of them use PEP 517/518 and one wants an editable install

Okay, but that's a different scenario from what you mentioned above. I was responding to what you wrote. Above you just said you wanted to install in develop mode when developing locally, and run CI/tox in pure PEP-517/518.

Like I said above, I don't know your exact situation. It just feels to me like you would have a lot of options given that you can structure things however you want in your repo and local environment.

[gaborbernat]

Well, I never said that I do install in develop mode when developing locally manually (I use tox for that too) or not in parallel with some other operation on the same repo. pip installs at the moment are parallel safe, your suggestion would break that constant, so it's not a true workaround.

[pfmoore]

Can we get a fix?

Even assuming someone pulls together a proposal that covers all the various issues that are getting raised, and gets agreement from everyone, it'll still need implementing. We're still only at the stage of everyone contributing their use case, and we haven't got much clarity on what is the best way forward yet. Stage one is probably for someone to step up and manage the various threads and discussions going on here (we really need one proposal to handle all the use cases, not multiple "temporary" solutions).

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.

But yes, we can get a fix, in due course.

PS It might actually be possible to get a PEP 517 extension supporting editable mode sorted in the 3 months before pip's next release - let's not waste all of the energy here on temporary solutions if we can harness it to address the underlying problem!

[pfmoore]

One other question - is this something new in pip 19.1? The PEP 517 support was introduced in 19.0, a few months ago - is there something in 19.1 that makes it worse? If not, then how come this issue has suddenly flared up now? Just coincidence?

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