classification
Title: Tag libffi build and sources in cpython-source-deps for 3.9.0b1
Type: enhancement Stage:
Components: Build, Windows Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: indygreg, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2020-04-15 15:02 by indygreg, last changed 2020-04-15 18:13 by steve.dower.

Messages (5)
msg366523 - (view) Author: Gregory Szorc (indygreg) * Date: 2020-04-15 15:02
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?
msg366525 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-15 15:20
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).
msg366526 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-15 15:23
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
msg366528 - (view) Author: Gregory Szorc (indygreg) * Date: 2020-04-15 16:16
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.
msg366534 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-15 18:13
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.
History
Date User Action Args
2020-04-15 18:13:00steve.dowersettitle: cpython-source-deps project missing release for libffi commits -> Tag libffi build and sources in cpython-source-deps for 3.9.0b1
messages: + msg366534
versions: + Python 3.9
2020-04-15 16:16:59indygregsetmessages: + msg366528
2020-04-15 15:23:10steve.dowersetmessages: + msg366526
2020-04-15 15:20:43steve.dowersetmessages: + msg366525
2020-04-15 15:02:42indygregcreate