Describe the bug A clear and concise description of what the bug is.
The most recent release only contains source code packages, no binaries. https://github.com/psf/black/releases/tag/20.8b1
To Reproduce Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen.
I expected a binary to be available, like previous releases.
Environment (please complete the following information):
N/A
Does this bug also happen on master? To answer this, you have two options:
N/A
Additional context Add any other context about the problem here.
20.8b0 is also missing a release binary: https://github.com/psf/black/releases/tag/20.8b0
You can find sources and wheels on PyPI, for at least both of those releases:
PyPI is the usual place to distribute Python packages, rather than GitHub Releases.
It was really nice to have the self enclosed binaries... not requiring a python environment really helped using this in CI.
Ah, do you mean like the black file at https://github.com/psf/black/releases/tag/19.10b0?
I'm not sure where that file comes from, @ambv did you do anything to generate it? It's an ELF file that works on Linux but I wasn't aware that we had anything in this repo that would build such a file.
Perhaps built with Pyinstaller or similar?
You can find sources and wheels on PyPI, for at least both of those releases:
PyPI is the usual place to distribute Python packages, rather than GitHub Releases.
@hugovk Maybe they've been removed (for reasons that I don't know about) since you posted this, but neither v20.8b0 or v20.8b1 have wheels on PyPI. Though v19.10b0 does.
cc @kratsg
They were removed due to a build error causing them to be out of date. We're hoping to have that fixed for 20.9 release coming the end of this month.
They were removed due to a build error causing them to be out of date. We're hoping to have that fixed for 20.9 release coming the end of this month.
Great! Thanks very much for the helpful and fast reply. :bow:
@JelleZijlstra, #362 asked for binary releases so Black could be run conveniently and without needing CPython 3.6+ set up. Linux and Windows binaries started to be automatically created and uploaded after their respective PRs were merged, #410 and #422.
20.8b0 and 20.8b1 don't have the Linux binary because the refactor to packages broke the Travis config. I have no idea whether any Windows binaries were successfully created and uploaded but regardless, we stopped used AppVeyor some time back.
I personally want to see platform specific binaries continue to be available as it enables more people to use Black without much cost. They were already created and uploaded automatically. Maybe this time we should use GitHub Actions instead of Travis CI + AppVeyor. ~For one, we could start providing binaries for MacOS!~ (er, Travis CI has support for Mac OS)
I personally want to see platform specific binaries continue to be available as it enables more people to use Black without much cost. They were already created and uploaded automatically. Maybe this time we should use GitHub Actions instead of Travis CI + AppVeyor. For one, we could start providing binaries for MacOS!
@ichard26 I might point you to the very nice work that @henryiii has done for Scikit-HEP to get this working very nicely with cibuildwheel. He even has developer instructions on the Scikit-HEP website for doing this all with GitHub Actions. You can see this working super nicely for boost-histogram.
Please let us know if you have any questions!
I think this could easily be a "universal" wheel (name may be slightly out of date now that it's Python 3 only), I don't think it needs any "true" binaries. There is a MyPyC extension, which could probably be built using cibuildwheel, though you could also provide a pure Python wheel too, as a fallback. I'm not sure how important / useful that is (or really what it is).
(Unless there really are compiled components that I didn't notice on quick glance)
I'd also recommend deploying to TestPyPI on (say) merges to master, that way the deploy mechanism is also regularly tested so there's no surprises on release day.
@matthewfeickert, I think @ichard26 is referring to self contained, binary packages, while you and several of us are referring to wheels on PyPI.
The developer instructions discuss downloading artifacts from any CI build, including PRs, so release day shouldn't be a surprise. :)
@matthewfeickert thanks for the information! I'm a bit lost though as cibuildwheel seems to builds .whl files (which are not binary files, just a ZIP archive that may contain compiled extensions) not actual OS native binary executables.
edit: oh thanks @henryiii, we posted at the same time :)
Level 0: SDist
Level 1: Wheels
Level 10: Binary self contained executables ;)
We are currently missing level 1 (and also level 10, I gather)
We already provide Pure Python wheels, but a mistake was made during build so the wheels were yanked. @ cooperlees already addressed this:
They were removed due to a build error causing them to be out of date. We're hoping to have that fixed for 20.9 release coming the end of this month.
As said already, the next release should have PEP 427 binaries unless another mistake is made :)
The developer instructions discuss downloading artifacts from any CI build, including PRs, so release day shouldn't be a surprise. :)
Ah yes, that's really handy for testing that the artifacts are generated properly. I still suggest uploading to TestPyPI to keep the upload mechanism itself well oiled :)
Most helpful comment
They were removed due to a build error causing them to be out of date. We're hoping to have that fixed for 20.9 release coming the end of this month.