Skip to content

Make python3 -m pep517.build work #7740

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
KOLANICH opened this issue Feb 13, 2020 · 9 comments · Fixed by #7742
Closed

Make python3 -m pep517.build work #7740

KOLANICH opened this issue Feb 13, 2020 · 9 comments · Fixed by #7742
Labels
auto-locked Outdated issues that have been locked by automation resolution: invalid Invalid issue/PR resolution: wrong project Should be reported elsewhere

Comments

@KOLANICH
Copy link
Contributor

No description provided.

@ghost ghost added the S: needs triage Issues/PRs that need to be triaged label Feb 13, 2020
KOLANICH added a commit to KOLANICH-tools/pip that referenced this issue Feb 13, 2020
@uranusjr
Copy link
Member

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.

@pradyunsg pradyunsg added resolution: invalid Invalid issue/PR resolution: wrong project Should be reported elsewhere labels Feb 14, 2020
@ghost ghost removed S: needs triage Issues/PRs that need to be triaged labels Feb 14, 2020
@pradyunsg
Copy link
Member

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

@KOLANICH
Copy link
Contributor Author

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

@uranusjr
Copy link
Member

I’d say different people have different definitions to “minor,” and even a one-liner may need discussions, as evident in this exact topic.

@pfmoore
Copy link
Member

pfmoore commented Feb 15, 2020

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:

  1. Some clarification of why 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.
  2. Some explanation of why this is something that is sufficiently useful to support in addition to the other ways of building pip that we already support.

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 added a commit to KOLANICH-tools/pip that referenced this issue Feb 17, 2020
@layday
Copy link
Member

layday commented Feb 18, 2020

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

@KOLANICH
Copy link
Contributor Author

@layday, thank you for the clarification.

BTW pypa/pyproject-hooks#76

@pfmoore
Copy link
Member

pfmoore commented Feb 18, 2020

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.

@uranusjr
Copy link
Member

uranusjr commented Feb 18, 2020

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.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 20, 2020
@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation resolution: invalid Invalid issue/PR resolution: wrong project Should be reported elsewhere
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants