This looks like a bug in pep517
. The build-backend
key is optional according to PEP 518, and pip’s configuration is perfectly valid as-is.
@KOLANICH Please file issues, with more information and proper descriptions in the future. There is an issue template for various kinds of issues, which exist because the maintainers expect that users will spend some time explaining what the issue is to make the jobs of the maintainers easier.
I know that filing the issue template results in the user also exploring what they're trying to solve, why pip is where the change needs to be made and how the user is suggesting the change to be made.
If you do not provide information, it will be difficult for the maintainers to understand or respond to your comments / issues, which makes it likely that your comments would be ignored in the future by the maintainers.
@pradyunsg, I have filed the issues only to satisfy towncrier check, which requires each PR to have a corresponding issue and a file in news
. IMHO it is more convenient to discuss in PRs themselves. And IMHO such a minor change doesn't deserve any items in the changelog.
I’d say different people have different definitions to “minor,” and even a one-liner may need discussions, as evident in this exact topic.
I’d say different people have different definitions to “minor"
Agreed. And that's pretty much why the issue/feature request templates lead you through thinking about the implications of what you're filing.
I have filed the issues only to satisfy towncrier check
That's very much not how we would expect someone requesting a change to think. If someone isn't willing to do the basic job of thinking through what they are asking for or reporting, and helping the developers understand the need and benefits, then it doesn't really give the impression that the request (or any PR that user might offer) is going to be sufficiently well thought through.
Yes, it's a nuisance having to go through all the steps in the template. But it's thinking someone has to do, and if the submitter isn't willing to, why would the pip developers do that work for them?
On this specific issue, there's nothing wrong with pip's pyproject.toml
in the sense that it follows the standards, and it supports our development workflow. It's not at all obvious to me that we even want to support python -m pep517.build .
to build pip. I'd like to see:
pep517.build
doesn't work with pip's current pyproject.toml
and at least a pointer to the discussion that confirms that this isn't simply a bug in the pep517
project.I'm not willing to spend my own time on doing those investigations, as I have no personal need for this, so if @KOLANICH isn't sufficiently motivated to do so either, I'd be quite happy to let this issue and PR languish until someone who does care enough decides to take it further.
@KOLANICH:
A build-system
without a build-backend
is meaningless in the context of PEP 517. The pip package is not compatible with PEP 517 if it does not specify a build-backend
. pip defaults to using pep517 for any package with a pyproject.toml
. It does this by passing setuptools.build_meta:__legacy__
to pep517 as the backend where the backend is not specified. pip is built using pep517 by pip but pep517 (invoked directly) cannot build pip because it does not provide a fallback for under-specified build systems. I assume pep517 would also refuse to build a package without a pyproject.toml
.
I presume the legacy build system bit was added to PEP 517 to "legitimise" usage by pip and I don't know (if anybody knows) if it should have any bearing on pep517. I suppose that all depends on whether pep517 is intended for general consumption.
@layday, thank you for the clarification.
I presume the legacy build system bit was added to PEP 517 to "legitimise" usage by pip
It was added (I believe) to allow front ends to have a unified approach to calling backends (for example, new tools that want to just implement PEP 517 mechanisms, and not include a whole "run setup.py
" alternative code path. Pip takes advantage of this to start moving away from the old setup.py
codepath, which has maintainability issues.
I don't know (if anybody knows) if it should have any bearing on pep517
I'd say that's a decision for the pep517
project maintainers. It's certainly arguable either way.
I suppose that all depends on whether pep517 is intended for general consumption.
I presume you mean pep517.build
here - the core backend handling in pep517
is used by pip, and is definitely for "general consumption". But my impression is that the status of pep517.build
is not yet clear.
I think the idea is to allow libraries to adapt PEP 518 without adapting PEP 517. This makes it possible to solve the build-time dependency problem (tell front ends to install extra stuff before building) without opting into PEP 517, which has a lot more implications.
Most helpful comment
@KOLANICH Please file issues, with more information and proper descriptions in the future. There is an issue template for various kinds of issues, which exist because the maintainers expect that users will spend some time explaining what the issue is to make the jobs of the maintainers easier.
I know that filing the issue template results in the user also exploring what they're trying to solve, why pip is where the change needs to be made and how the user is suggesting the change to be made.
If you do not provide information, it will be difficult for the maintainers to understand or respond to your comments / issues, which makes it likely that your comments would be ignored in the future by the maintainers.