Expose command to build packages

[jaraco]

Currently, there's pep517.check that checks that a package can successfully build sdist and wheels for a package. Similar to that, it should be possible to actually build a package, either the sdist or the wheel or both... something that a CI tool could use to build the package prior to using twine to upload it. This would address pypa/packaging-problems#219.

[jaraco]

I'm thinking this:

python -m pep517.build [-s|--source] [-b|--binary] [-o|--out-dir out-dir] <project-dir>

Default is to build both source and binary (wheel) dists and put them in './dist', comparable to what setup.py sdist bdist_wheel does. Passing either -s or -b would produce only that dist.

[pfmoore]

I have a slight concern over user confusion. There's a discussion in the packaging-problems repo about there being too many tools involved in the packaging ecosystem. This would add another one (and until pip gets a "build" or "sdist" command, it's the only generic way to make a sdist).

It's not enough that I object to the proposal (and your command line syntax looks fine), but I'd see it as a "useful utility" rather than a definitive implementation - at least for now.

[takluyver]

I'd lean towards saying the command line interface should be separate, probably part of pip. Pip wheel is presumably already going to grow pep 517 support. I'm pretty sure that once you get into creating build environments and installing dependencies, there's a load of extra complexity that I've ignored - people will want to get dependencies from different sources, use pre-release versions of them, control how they're installed, and so on. We'd end up duplicating lots of options that pip already has. This reasoning applies to check as well. It's not there by any carefully considered design - I just wanted a way to do a basic sanity check of all the pieces, and this was an easy place to put it.

…

On Wed, 12 Dec 2018, 8:51 p.m. Paul Moore ***@***.*** wrote: I have a slight concern over user confusion. There's a discussion in the packaging-problems repo about there being too many tools involved in the packaging ecosystem. This would add another one (and until pip gets a "build" or "sdist" command, it's the *only* generic way to make a sdist). It's not enough that I object to the proposal (and your command line syntax looks fine), but I'd see it as a "useful utility" rather than a definitive implementation - at least for now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUA9S8D31yHtwSTvfD2VAmb6YkbRlB3ks5u4Ww_gaJpZM4ZQN4H> .

[pfmoore]

Yes, one thing that very rapidly becomes an issue with any form of "general packaging library" is that all the myriad of options pip has for controlling what gets installed, network options like proxies, etc etc, all have legitimate reasons for existing, and all tools should (in theory) support them. Look at pip's "build environment" code for how complex it gets ;-)

I'm not sure that counts as an argument for loading all of that functionality into pip. I'd like to think that having a general "install option management" library would be a more reusable option, and I don't think it's healthy for the ecosystem that any tool that isn't pip either has to reimplement huge parts of pip or forever suffer being considered "incomplete". But it's a lot of work to do that, and it would be very easy to end up with a Java-esque "installer option factory builder manager class" style of interface :-)

All of which is a long-winded way of saying that this is why I think any command line interface in the pep517 library should be considered provisional at this point.