Add 'pep517' command

[EpicWink]

Add command-line app pep517 to run the provided scripts pep517.build, pep517.check and pep517.meta

[takluyver]

I'm -0.5 on this because, as I've said elsewhere, pep517 is intended as a low-level component to be used in tools like pip, not a user-visible tool in its own right. The python -m interfaces are there more or less as a proof of concept - e.g. they don't really offer proper control over how build dependencies are found and installed. So I don't want to 'advertise' them too prominently.

I don't feel very strongly about this, though (hence 0.5), so I'll leave it open for now in case other people are more keen for it.

[pfmoore]

I think the packaging ecosystem needs a library that handles the various aspects of PEP 517, and as far as I'm concerned (as a pip maintainer and consumer of this project) this project serves that purpose (and could be developed further in this direction).

The community seems to be finding a need for a pip517.build style command, which is fine. I'd prefer it if that command were a separate tool, which used this library, but

1. That tool would be a very thin wrapper on the functionality here.
2. The existing proof of concept command line interface here suggests that the intention is to support that command here.

IMO this project would benefit from a clear statement of purpose, explaining precisely what its scope is, and what (if anything) is out of scope. In particular, if a command line interface is out of scope, we would be better to make that clear sooner rather than later, before too many projects come to rely on what's already present.

As one of the two people with write access to this repository, I'd prefer it if it were a pure library, and the command line tool was removed, with that role being covered by a different project. That reflects my preference for focusing on internal library code, and not the UI issues of a command line tool. But it would require someone else to step up and offer to write/maintain that tool.

[takluyver]

I'm also concerned that it's currently impossible to implement a PEP-517 builder independently of pip, because you need it to install the build dependencies. And shelling out to pip doesn't feel like the kind of thing that low-level components do.

[pfmoore]

That's a good point. Maybe we should let users (of the library code, not the CLI!) supply functions to (1) install packages, and (2) build a virtual environment? Then the internal code is generic, and callers can deal with the question? (We could default to pip/virtualenv for convenience, if that seemed like a good idea).

[pradyunsg]

I'm personally a strong -1 on this.

I know folks have started recommending using pep517.build as a best practice (I've seen at least 2 separate PyPA members do so on discuss.python.org, on the basis of this works + practicality beats purity).

IMO this library is not a user facing tool but lower level plumbing and pep517.build is not the way I want us to expose build-a-distribution functionality longer-term. But that said, it's @takluyver's call whether to make this a user facing tool.

[pradyunsg]

FWIW, I'm also fairly annoyed that the discuss.python.org discussion about this ended up going the complete different direction toward us discussing "what would an ideal python workflow tool look like", which is a much broader question than we needed to answer the original question of do we want pip build or pep517.build or a new tool. :/

[pfmoore]

OK, so if we want to go for a "pep517 is a library" position (which it sounds like a number of us do) the big question is, who's going to write and maintain a stopgap equivalent of pep517.build? I don't think we can expect people to wait for discussions around pip build to settle down, nor do I think we can just drop the command line interface unilaterally. But I think we need to make a clear statement sooner rather than later.

Suggestion:

1. Expand on the comment in the README that the command line tool is experimental. Note that feature requests for it will be rejected, that it will at some point be removed.
2. Maybe even add a warning to the CLI saying "unsupported test code - please consider calling the library API from within your automation script rather than using the CLI".
3. Close any issues/PRs related to the CLI with reference to this policy.

This leaves us with pep517.build as the stopgap solution, but hopefully with it being much clearer that this is the case.

Ideally, I'd like to suggest that the people interested in the CLI get together and write/maintain a separate pep517cli project, but it could end up being relatively high profile, and not many people want that level of notoriety 🙂

[takluyver]

Maybe we should let users (of the library code, not the CLI!) supply functions to (1) install packages, and (2) build a virtual environment?

For that scenario, I'd recommend that people use the Pep517HookCaller API - i.e. use pep517 to get a list of build requirements, and then deal with environment setup and package installation from there. That's much simpler to define than an interface based on callbacks.

After all, the conceptual code to call the hooks and use an environment is just a few lines - I'd prefer that people copied and modified this rather than trying to build an abstraction:

https://github.com/pypa/pep517/blob/3f1949a727f879a997afeaa76ca10bbe2ef70011/pep517/envbuild.py#L141-L145

[encukou]

I'm also concerned that it's currently impossible to implement a PEP-517 builder independently of pip, because you need it to install the build dependencies.

That's not the case! We'd like to use a non-pip PEP-517 builder in Fedora, where the buildsystem has no access to the Internet (all sources must be auditable). Currently we still use pip, but as pip wheel --no-deps --no-build-isolation. Wheels are then re-packaged as RPMs, so they're compatible with the system package manager. Before building a package, get_requires_for_build_wheel is called and RPMs for the requirements are installed. No pip :) (Also no use of the pep517 library yet; the plan is to switch.)

[takluyver]

Thanks, that's good to know about!

Maybe what I was trying to say is more like: a low-level component can't do the complete process of building a wheel/sdist, because that inherently involves high-level operations like installing packages. That's true whether the packages are handled by pip or rpm.

So what we end up with is a low-level library with a proof-of-concept high-level wrapper to do that in one particular way (create a rather hackish 'build environment' and then shell out to pip with the default settings). It's almost unfortunate that that proof-of-concept is probably 'good enough' for 90% of likely use cases, because it makes it seems like it's almost a complete tool, when in fact it's nothing of the kind.

[sinoroc]

Point of view from someone external to the development and maintenance itself:

As I commented in discuss.python.org, I wish these commands were added to twine instead. I believe it would offer a great workflow for people in the role of a Python library (or application) developer: check build backend, build distributions, check distributions, publish distributions.

I think pep517 is great as a library that can be used in other projects (pip, twine, etc.), and should stay a library first, keeping the already existing commands (-m pep517.build) is fine though (at least until some other tool takes over and integrates them with a good UI/UX).

[encukou]

I guess this is getting off-topic, and we're agreeing with each other, but let me expand in case this is interesting to you: In the Fedora build, a tool can't install packages. A tool is executed in an isolated environment, and if a dependency is missing, the most it can do is fail with the message "I need package X to work". (At which point the container/VM can be modified externally, and the tool can be run again.) In other words, I can't supply a Python function to install packages; I need to call get_requires_for_build_wheel ahead of time and build the environment according to that.

I guess it all goes back to say that designing a tool is probably more complex than what pep517 wants to do. (PEP 517 the document, on the other hand, is pretty amazing in allowing strange non-pip use cases!)

[takluyver]

Thanks @encukou - I think that supports my argument that pep517 should stay primarily as a low-level component.

[pradyunsg]

@takluyver So, would you agree that we should eventually drop the higher level proof-of-concept bits of pep517 (like environment setup etc) and only keep the wrappers here?

[pfmoore]

It sounds very much like we're getting consensus here that only pep517.wrappers is core to this library, all of the rest is just example/proof-of-concept code. Is that accurate?

If so, then that would certainly imply rejecting this PR and discouraging users from using the pep517.build command line tool.

I'd also suggest in the short-to-medium term, moving the CLI and all of the non-wrapper code to an examples directory, rather than having it as a subpackage. We could then consider exposing the wrappers from the top-level pep517 namespace, rather from pep517.wrappers.

[takluyver]

I'm OK with moving the higher-level wrappers to an examples folder or similar, but it seems kind of hostile to do so when there's nothing we can suggest people use instead for the common case where you want to install build dependencies from PyPI with pip's standard options.

[pfmoore]

the common case where you want to install build dependencies from PyPI with pip's standard options.

By that do you mean the CLI pep517.build or the higher-level API?

As far as I can tell, the pep517.build command can be mostly replaced by python -m pip wheel --no-deps .. I'm not completely clear why people aren't happy with that.

And I'm not aware of anyone using the high-level API, so I assumed moving it wouldn't affect anyone. But I'm fine with a deprecation period if we feel that it's worthwhile.

What I'm not fine with, is leaving things in limbo, where we don't want to support and improve the CLI and higher-level APIs, but we won't drop them. I'd hope that somebody who does want to support them would take up that job, and I'd like it if explicitly dropping support here prompted someone to do so. But if not, then so be it, I guess.

With my pip maintainer hat on, I'm mildly concerned by the current status of this project. We rely on the wrapper code here, and if this project became unsupported we'd have a problem. But developer energy and interest here seems to be getting sapped by the continual debates over the higher level features. The project seems to be attracting interest, but from people looking at the "build tool" aspect, not the "low level library" one, so I'm not sure how much that helps pip's interest.

But I've spent way more time today on this topic than I intended, and I've made my point (to the stage where I think I'm repeating myself) so I'll leave it here now.

[takluyver]

Sorry, yes, I was thinking of the rough CLI, and I had forgotten about pip wheel. I don't think there's any pip sdist, though?

[pfmoore]

I don't think there's any pip sdist, though?

Correct, there isn't, I'd forgotten the command built sdists as well.

[pradyunsg]

Yea... I am painfully aware of the missing local-dir -> sdist transition in pip's CLI. Hence the question about dropping the additional functionality "eventually". :)

But, hey, it helps to know that @takluyver is open to the idea of all logic other than the hook interaction moving elsewhere.

[EpicWink]

It seems like most here agree that this PR is counter to this project's design goals. If this is true, could a maintainer close this please?

[pradyunsg]

Indeed! Many thanks for the PR @EpicWink! ^>^

Also, thanks @encukou for providing useful insights into how a lower-level library like this is useful, and @sinoroc for your inputs on the overall situation.

[gaborbernat]

As far as I can tell, the pep517.build command can be mostly replaced by python -m pip wheel --no-deps .. I'm not completely clear why people aren't happy with that.

Even upon introduction of pip sdist (which still feels far) will not be equivalent due to:

• will require two pip invocations as opposed to one of current py -m pep517.build -s -b.
• pip is released quarterly, so if someone runs into an issue with pip sdist/wheel they'll have to wait at least until the next release window to get a fix; while this project might release faster.

IMHO people can already use py -m pep517.build/check today, there's no harm in exposing that directly too via a pep517 build/check. I don't think we should extend the interface any more than it is; however, there's value in providing those directly too (autocomplete and pipx support come to mind straight up).

[pfmoore]

As someone who is "sort of" a maintainer here¹ my concern is maintainability. There are a lot of potential ways in which the "build an isolated environment" code in this project is limited, and I don't think we have the maintainer bandwidth to address those. Basically all of the pip command line options (proxy support, extra index options, authentication, etc) are unavailable, and if a pep517.build tool were to be promoted as the "official" approach, we'd need to have an answer for people who need them. Even just saying "no, this isn't supported" takes up developer bandwidth, when the question comes up often enough.

I'd like to see a build tool appear that had good answers to these questions. And honestly, I'm at best lukewarm on a pip build command. On the other hand, it would be really easy² for someone to take the code here as the basis for a standalone tool that did what build and check currently do, and start the process of improving them. No-one seems willing to take the lead on that, though...

¹ By which I mean that I have commit rights, but I don't in practice exercise them much at the moment. The main reason I don't is precisely because I see the time commitment around pep517.build being more than I can manage - I'm OK with supporting the wrappers, but not the build part as it stands. ² By which, of course, I mean that it probably wouldn't be easy, but in precisely the same way as "just" making pep517.build a supported interface isn't easy 😉

[gaborbernat]

On the other hand, it would be really easy² for someone to take the code here as the basis for a standalone tool that did what build and check currently do, and start the process of improving them. No-one seems willing to take the lead on that, though...

@EpicWink did exactly this. I don't think there's the bandwidth for a glorious one-command packaging tool. However, must we really force pep517-cli project to just wrap exactly what this project offers now?

Even just saying "no, this isn't supported" takes up developer bandwidth, when the question comes up often enough.

I mean whoever picks up pep517-cli project would already have to do this (and I'm tempted to say I'd be willing to tackle that, considering pip build is at best not available for a good while), so can't we just make him maintainer of this project and provide it within?

[pfmoore]

@EpicWink did exactly this.

Oh, cool, I didn't notice that 🙂 Thanks for the correction.

However, must we really force pep517-cli project to just wrap exactly what this project offers now?

Not "just" to do that, but to take on the role of supporting and extending it into the future.

I think at this point I'm just reiterating the points made earlier in this thread, so I'll leave it to others to comment further. As I said, my personal interest is solely in the wrapper functionality.

[gaborbernat]

Not "just" to do that, but to take on the role of supporting and extending it into the future.

Feels to me we're refusing a low hanging fruit in hope of that low hanging fruit will force someone to pick up a heavy burden. I don't think we need to commit to extending it any further, we can just say this is what we support for now. We really are talking here about exposing python -m pep517.build/check under more convenient pep517 build/check, not coming up with the answer to all Python packaging. For the latter, in the last 10 years, we had probably two meaningful attempts (flit at a limited level and poetry at a wider level); so not sure we have the community has the resources for it; and generally is such decisive subject I don't think we can reach consensus on it (proof of this is that the only project that got reasonably far is poetry just does what the maintainer thinks, rather than seek consensus).

[sinoroc]

(I tried to re-read the whole discussion, and couldn't find this argument, but maybe it was mentioned already.)

It looks like it could cause the same kind of confusion that pip install vs. python -m pip install already does.

Personally I don't see the need for a pep517 console script if the python -m pep517.something executable modules already do the same or a similar job. I don't see much convenience in having a slightly shorter version of a command that often is written down in full in a Makefile, tox.ini, or any other kind of CI script anyway.

[gaborbernat]

. I don't see much convenience in having a slightly shorter version of a command that often is written down in full in a Makefile, tox.ini, or any other kind of CI script anyway.

It's not just being shorter, it's about being able to be managed via pipx. Forcing to be invoked via python -m forces people to install it either in their userspace or system python; not into a virtual environment.

[sinoroc]

(Unrelated, but I see. I always assumed that pipx in addition to the console scripts could handle packages, modules, or functions as entry points, like for example pex --entry-point and shiv --entry-point.)

[gaborbernat]

Well that would require pipx to suddenly be able to discover __main__.py modules in packages, and then figuring out how to map that to command-line interface (should it be pep517-build and pep517-check or should it be pep517.build?) The maintainers of pipx decided not to take on this burden and instead leave it to packages to explicitly state what they want to expose as CLI interface.

[sinoroc]

(True, it does not seem straightforward to reliably discover such entry points and figure out sensible names for them, I agree.)

Does a pipx-installed pep517 script make sense, though? Maybe I am missing something important here that flaws my logic. In order to build patform-specific wheels that would be counter-productive, wouldn't it? I don't know much about pipx but I assume it would run python -m pep517.build from within its own dedicated virtual environment, is that right?

On the other hand, I could potentially see the advantage of having a pep517.pyz with a neutral shebang (assuming it is possible at all, knowing the limitations of zipapps).

[gaborbernat]

Does a pipx-installed pep517 script make sense, though? In order to build patform-specific wheels, that would be counter-productive wouldn't it?

Sure might not handle platform-specific wheels, but does not worse than pip wheel does, and does it without the need of the cryptic --no-deps flag. However, it works perfectly for universal wheels (e.g py3 only) and source distribution creation. The first is 90% of use real-world packages, while the second at the moment is a big missing gap, given pip build sdist is not a thing and there does not seem to be a strong will within pip maintainers to add it anytime soon. I consider pep517.build -s to be much better than using python setup.py sdist where users must ensure themselves that the PEP-518 dependencies are present.

[pradyunsg]

they'll have to wait at least until the next release window to get a fix; while this project might release faster.

No? pip can (and does!) make bugfix releases more frequently. The quarterly schedule is for "make sure we at least do one every quarter, if there's stuff in master".

[gaborbernat]

@pradyunsg let me then phrase my point instead of as it is slower than pep517 directly could do (looking through the pip bugfix releases they generally happen 3-14 days after the release, I'd guess mostly because the release is usually held up waiting for other critical bug fixes to make it in). But either way, this is a moot point, as said above pip does not do pip build and seems to be not a great interest from people to make it, so in the interim which probably will not be few weeks (I know pip build was already talked last summer, and we did not make much progress on it, and as @pfmoore pointed out above he's still not convinced that should happen - mostly due to lack of resources to work on it) pep517 offering the cli entry point would be very useful. I'd hope to add the already exposed -m pep517.build becoming pep517 available in the cli would require less consensus than agreeing on how this should fit in pip.