Closed matthewfeickert closed 4 months ago
BTW, it is fine to open a PR in "draft" mode before you're ready to merge it or have someone review it. This is usually where most of the post-planning and implementation focused discussions happen on GitHub.
I'm sure I'll be making use of "draft" mode! 😆 I'm currently stuck on trying to get the workflow to use the python build module. The guide uses pipx, which seems to be integrated into GH Actions.
So far, I've attempted to get each OS to set up Python 3.11 and run python -m pip install build
, which seems to work, but the workflow still fails when it's time to use the module.
You don't need to upload the wheels anywhere, binary wheels are not guaranteed to work anywhere except the machine they were built on unless you use cibuildwheel. (Windows pretty much should work, but macOS will require a very recent macOS and Linux won't work at all without the extra steps that cibuildwheel will do for you).
I'd recommend pipx run build --sdist
generally. Where's the workflow for the image above?
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: python -m pip install build
- run: python -m build .
Should always have a build module.
Where's the workflow for the image above?
Ah, yes, jobs are separate. Steps run in a job. Each job is an unrelated VM instance.
If you want to communicate between jobs (needs:
), you have to use upload-artifact / download-artifact to send files. They don't share anything else.
Can you do that with something like an installed package?
You can do it with wheels and SDists, not with the installed environments.
Trying to find an example, lots of my packages now use hynek/build-and-inspect-python-package@v2
, which is a composite action, meaning it contains 4-5 steps which include the build step and the artifact upload step.
Here's one of my older ones where you can see files being transferred between jobs:
https://github.com/scikit-build/scikit-build/blob/main/.github/workflows/cd.yml
You can also download the artifacts from the job for some period of time.
You don't need to upload the wheels anywhere, binary wheels are not guaranteed to work anywhere except the machine they were built on unless you use cibuildwheel.
Yeah, the point here was just to get familiar with the idea of uploading build artifacts, but it is a good point that this can be done just via uploading the sdist and the wheel uploads can be ignored.
In a PR add a GitHub Actions based workflow to the project that:
ubuntu-latest
runnermacos-latest
, andwindows-latest
runnersTo get started, read through the GitHub Actions: Intro guide that @henryiii wrote for Scientific Python and ask any questions that you have in this Issue. :+1:
We'll just start with doing a simple build here (e.g.
python -m build .
), and then move to usingcibuildwheel
in a follow up PR.