Deprecate call to setup.py install when building a wheel failed for source distributions without pyproject.toml

[sbidoul]

This is one of a series of deprecations meant to collect feedback on the ultimate goal of always installing source distributions by first building a wheel and then installing from it.

This specific issue is about the case when pip calls setup.py bdist_wheel and that fails.
In that case, pip currently displays the build error and continues installation by attempting a setup.py install.

In a future version, pip will not attempt setup.py install in that case, and fail the installation right away.

Towards #8102

[pradyunsg]

Thanks for clearly providing all the relevant information here @djhenderson. I think the issue tracker for Pillow (where you've filed an issue) is the correct place to get help with your issue. :)

[pradyunsg]

This discussion is spiralling faster than I can keep up. Since I'm trying to be on vacation, I'm gonna step away from this after this response.

I don't understand how you could realize that for public-pypi and not consider private-pypi at all in your transition plans.

I am concerned that you guys are cagey and don't want to go on the record about whether pip supports private registries.

I'm not being cagey -- I have limited time and there's way too much for me to respond to. And, as I've already stated, posting a wall of questions isn't particularly conducive to constructive discussion -- which I imagine contributed to you never getting a response to this from anyone else.

As far the question goes, pip does support private package indexes and I can say that we do make changes and do consider their usage a lot when designing things and planning migrations.

However, that doesn't mean that private package indexes can do whatever though. Nor does it mean that pip needs to support that "whatever" indefinitely. Being able to use the latest pip which contains potentially-breaking changes with non-compliant private package indexes isn't a reasonable expectation.

If organisations/commercial providers can't move at the speed that we move at, that's fine -- it's reasonable that they stick to older versions of open source software in those situations and opt out of "free" support from the maintainers of that open source software.

don't have pip install . telling me to remove it and pip install -e . telling me to add it back!

Got an example of this? If this is happening, that's a bug.

folks here are basically saying "the tools contradict each other, we know that, we know it's bad for users, and we think users should accept this status quo anyway".

Here's my attempt to summarize the status quo...

We're going to be bringing tools into a consistent and saner model, and things should be less bad on the other side for everyone. There's going to be a migration cost and pip is the latest piece to start warning people about the upcoming migration. Python packaging tools are all going to be migrating in the future (or already have) but their timelines may not be as aligned as a full-time funded team of engineers and project managers would be able to provide to end users.

[prithwis]

This is one of a series of deprecations meant to collect feedback on the ultimate goal of always installing source distributions by first building a wheel and then installing from it.

This specific issue is about the case when pip calls setup.py bdist_wheel and that fails. In that case, pip currently displays the build error and continues installation by attempting a setup.py install.

In a future version, pip will not attempt setup.py install in that case, and fail the installation right away.

Towards #8102

ERROR: Failed building wheel for box2d-py -- what should I do? confused

[sbidoul]

@prithwis we can't help without seeing a detailed log, but it is very likely an issue is with the box2d-py project.