Use python -m build for PEP517 Compatibility

[kojiromike]

SEMVER Update Type:

• Major
• Minor
• Patch

Description:

• Replace python -m wheel with python -m build.
• Fully support most of python -m build's parameters.

Motivation:

build is a simple, correct PEP 517 build frontend. Projects that support PEP 517, but not setuptools, will still build.

Checklist:

• All new jobs, commands, executors, parameters have descriptions.
• Usage Example version numbers have been updated.
• Changelog has been updated.

[Jaryt]

This looks great! Thank you a bunch for this PR, will run the tests for it here shortly, and get it merged ASAP 👏

[orb-publisher]

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/circleci/python?version=dev:1b943c894d895abfc10735654e7901dc225765ef

[Jaryt]

Hi @kojiromike, just a few things before I proceed with merging. 'wheel' still seems to be actively maintained, and might still be a preference to some users. Do you believe it would be worth supporting both, and instead making a PEP517-specific build command? Or better yet, is build backward compatible with wheel in most scenarios?

Thanks!

[kojiromike]

There's nothing wrong with supporting both if you're open to it. Both commands produce a wheel, so they ought to product compatible results. If there's a difference, it's that by default build builds an sdist first and uses that to build the wheel, whereas wheel builds the wheel directly from the source. The build approach is especially useful if the packager plans to ship both the wheel and the sdist, because they'll be more consistent than if they're built independently. But for the majority of packages it won't make a difference anyway.

[Jaryt]

@kojiromike Excellent! Thank you for the great explanation. I figured this was the case but just wanted to verify. We're discussing how to best incorporate this - do we make this a new command, or keep the dist command consolidated? I believe the latter is the right approach, however, then we have a few hanging parameters that don't get used. That's not a deal breaker as we have that same scenario in other orbs.

One last question (that I will also look into momentarily), but are any of these new parameters that are build specific, also applicable to wheel? I don't expect them to completely correlate, but since we're parameterizing those values it would be excellent to utilize them in wheel, where applicable.

[Jaryt]

Going to merge this into a temp branch so that I can make the changes discussed above 😄

[orb-publisher]

Your development orb has been published. It will expire in 30 days.
You can preview what this will look like on the CircleCI Orb Registry at the following link:
https://circleci.com/developer/orbs/orb/circleci/python?version=dev:c5893890c92ab54149a92ef89715426f1694cc4f