On Mon, 4 Oct 2021 at 08:21, Antoine Pitrou <anto...@python.org> wrote: > > On Sat, 2 Oct 2021 13:27:03 +0100 > Paul Moore <p.f.mo...@gmail.com> wrote: > > On Sat, 2 Oct 2021 at 12:20, Thomas Grainger <tagr...@gmail.com> wrote: > > > > > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 > > > > I agree with the comment made on that issue - this isn't the right way > > to handle the problem. We need to encourage projects to opt into the > > new approach and remove the legacy path once it's no longer needed. We > > should *not* maintain the "old style" approach indefinitely, hiding > > the fact that it's no longer the correct approach by having some sort > > of "auto convert" logic in the tools. > > Can you explain what the "old style" approach is here? I would hope > for the "old style" approach to be deprecated (with a *visible* > warning message) for at least 2 years before it is removed.
I'm talking about projects adopting a `pyproject.toml` configuration file that specifies the build backend to use (in this case setuptools). The `pyproject.toml` style was standardised in PEP 517 about 4 years ago now, and projects have been gradually adopting it. As you say, there's a long tail of projects who have no immediate need to switch, but we're working on smoothing that transition as much as we can. Deprecation is a complex process, and not really a python-dev question, but for the record, pip (and PEP 517) have a mechanism for using the new-style hooks even for older projects that haven't adopted it. That, plus a "build isolation" mechanism, allows pip to work even if setuptools is not present. We're transitioning to making that the default behaviour, but that process isn't yet complete. Although even when it *is* complete, we may have options allowing use of the old behaviour (`--no-build-isolation, --no-use-pep517) for some time after that. Regarding warning when the old `setup.py` mechanism is used instead of the new PEP 517 hooks, that's a matter for setuptools to decide, and I can't speak for them. It's also not relevant to when ensurepip drops inclusion of setuptools, as the ensurepip requirement is only that *pip* no longer needs setuptools, and as I said, we're hoping to make that mostly transparent. We *might* also be able to add a warning in pip, to catch the case where setuptools *doesn't* have the warning, but honestly we will probably be mostly OK from our side of things with just advising the user to install setuptools manually in the (increasingly rare) cases where we can't work out to install it automatically. > It is nice that well-maintained packages with lots of contributors get > frequent releases and keep up with the pace of changes in the packaging > ecosystem, but please don't forget that there's a long tail of packages > that are updated infrequently and but still work properly and perform > an important function for some parts of the user base. We (the packaging community) are *extremely* aware of this, yes. If you're interested in helping out, then these sorts of discussions happen on the packaging area in Discourse, and (for project-specific items) on the pip and setuptools trackers. We'd love more help there - packaging for Python is critically under-resourced! - so please feel welcome to come along and join in the work :-) Paul _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M6CZYUEKKNZC6ANSAULKP7JYWUJY6V63/ Code of Conduct: http://python.org/psf/codeofconduct/
