Add build-system to pyproject.toml for PEP 517 (-m build) #323
Conversation
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #323 +/- ##
=======================================
Coverage 96.78% 96.78%
=======================================
Files 20 20
Lines 1183 1183
Branches 106 106
=======================================
Hits 1145 1145
Misses 20 20
Partials 18 18 Continue to review full report at Codecov.
|
altendky
changed the title
| python -m build --sdist --outdir ${toxinidir}/dist/ ${toxinidir} | ||
| tar -xvf ${toxinidir}/dist/* | ||
| cd * | ||
| # build the wheel from the sdist |
There was a problem hiding this comment.
Why do we need to build the wheel from the sdist, and not build the wheel directly? Feels like you don't need this indirection, you're only testing the correctness of setuptools backend at best.
There was a problem hiding this comment.
It makes sure that the sdist was in the path of what is tested. Trio does it. Made enough sense to me to do it too. I don't know what errors I might be able to have that could make a wheel work but an sdist be broken. It may well be 'excessive' but it do you see harm that it could do? The overall goal is to make sure that the actual files to be published are what is tested. Not just that 'some wheel built in some situation is tested'. Likewise for sdist.
There was a problem hiding this comment.
https://twistedmatrix.com/trac/ticket/10103 would have been caught if I'd have used this strategy
There was a problem hiding this comment.
If you go down this path why not also test that direct wheel build works? I'm sure they'll be some edge case in some situation when src to sdist works, sdist to wheel also, but src to wheel does not 🤷♂️
There was a problem hiding this comment.
And it's not some wheel in some situation. The builder ensures it's a pep 517/518 situation.
There was a problem hiding this comment.
How do you generate your packages to upload to pypi?
There was a problem hiding this comment.
This code that we are discussing. They are built, archived in GitHub Actions. Downloaded for tests and checks. If all is still well, they are downloaded and then published to PyPI. At least that is the presently-being-developed workflow. This PR does the first bit, #315 is adding the automated PyPI upload.
There was a problem hiding this comment.
Perhaps you want a wheel-from-sdist option for build project so you don't have to do this dance 🤷🏻
There was a problem hiding this comment.
Maybe. We'll see what everyone else thinks I guess. pypa/build#257
Like #314 but with a prebuild step using build instead of tox-wheel integrated into the tox run. It has been expressed that tox-wheel has the added benefit of being the same thing in CI and locally. I do like this but something about that setup is broken with PyPy on Windows, and this works... Also, using tox-wheel in CI is a bit odd since every tox environment in every job would be rebuilding the wheel rather than building it once and testing that to-be-published artifact everywhere. So, I think some drawbacks both ways. Also, not being the same as Twisted is a downside. Then again, Twisted isn't testing on PyPy on macOS or Windows.
Note that the code in
tox_build.shcan't be put intox.inisince it uses wildcards and tox doesn't support those (but yay, tox 4.1 maybe will).