The https://github.com/python/cpython-source-deps project is missing a source archive release for commits to libffi needed to support building on Windows.

The latest release of libffi is version libffi-3.3.0-rc0-r1, which corresponds to https://github.com/python/cpython-source-deps/commit/8ba2b2c38744420a235e3e7f419cce2591aaf331.

There have been a few commits since that release: https://github.com/python/cpython-source-deps/compare/8ba2b2c38744420a235e3e7f419cce2591aaf331...libffi

Most notable is https://github.com/python/cpython-source-deps/commit/ed22026f39b37f892ded95d7b30e77dfb5126334 because without this commit, the source is not buildable on Windows using MSVC, at least not with the  prepare_ffi.bat script in CPython's Git repository. (Build fails due to issues with FFI_BUILDING_DLL).

Would it be possible to cut a new tag and upload a source tarball for libffi?

In master, we build against the latest build out of that repo, which comes from the libffi branch (not the 3.3.0 RC).

In 3.8 (and 3.7? I forget) we use the 3.3.0 RC build. There's no later release from libffi (last I checked), and no important fixes since then (only ARM64 support, which we contributed).

We'll probably tag for 3.9.0b1 and retarget the master branch to take that one, so that we can control updates that go into that release. But right now there isn't anything we want to tag right now (and GitHub generates the tarball itself, so we don't have to upload anything - you can get the branch tip through the "Download" button on the front page).

To save the clicks, here's the URL that will get the latest sources from the libffi branch: https://github.com/python/cpython-source-deps/archive/libffi.zip

I don't like utilizing the dynamic archive links like https://github.com/python/cpython-source-deps/archive/libffi.zip (even if you pin the commit) because GitHub does not guarantee the file content is deterministic over time. I perform SHA-256 validation of all dependencies I download from the Internet. And if I rely on the /archive/ URLs, all it takes is GitHub updating some library that subtly changes the tar/zip structure and my hashes are invalidated.

Release artifacts are immutable and don't have this problem.

As it stands, I will likely `git clone` and check out the commit I need. Although I would prefer a release artifact.

When we make a beta release, you can have a release artifact. Until then, if you're building against the master branch, you can use the dependency's "master" branch.

I've renamed the issue so it can serve as a reminder to tag whatever version we use for beta 1.