Configuration files for download links

[YannickJadoul]

Something that crossed my mind, a few days ago: since there needs to be a new release every time download links change or new Python versions get added or ..., should we do something similar as for the docker images and their versions and have them in a separate file that's read by cibuildwheel?

I can't make up my mind on whether this is a potentially good idea, or not, so I thought I'd just throw this out there. Curious to hear pros and cons :-)

[Czaki]

It is release moved in another place. And such release need some infrastructure for hosting. And still one of cons of cibuildwheel is version pining which gave reproducibility in builds. so it produce additional parameters need.

As I good understand main problem are pypy download links. (because bump of cpython version are does not break old build system). Maybe ask pypy maintainers for provide some mapping files on their website?

[joerick]

I can see two ways to interpret this-

1. Python download links distributed outside the current release process (this seems to be what @Czaki had assumed).

2. A config file in the repo, distributed in the package like pinned_docker_images.cfg. This is then read by the various build scripts to extract the download URLs.

which one were you thinking @YannickJadoul ? curious also to hear what advantages this might have.

[Czaki]

2. A config file in the repo, distributed in the package like pinned_docker_images.cfg. This is then read by the various build scripts to extract the download URLs.

Second one still need create new release and @YannickJadoul wrote

since there needs to be a new release every time download links change or new Python versions get added

[YannickJadoul]

I was indeed thinking 2., which would allow (just like pinned_docker_images.cfg) to be (partially) overridden by the user, if necessary. Of course we'd update with new releases.

curious also to hear what advantages this might have.

I'm not sure, but I was wondering if we could escape the new-release-for-every-Python-or-PyPy-update, this way. E.g., to #426, you could say to just provide a config file with updated download links, instead of forcing an update.

But again, I'm not convinced myself this is a good idea (especially with respect to reproducable builds and using tested Python versions). It's just something that crossed my mind.

[YannickJadoul]

1. Python download links distributed outside the current release process (this seems to be what @Czaki had assumed).

This could also be interesting, though. We could link to some repository + commit, allowing the user to set the commit to choose newer versions in an old version of cibuildwheel.

Taking a step backwards, and gathering my thoughts: I think the main thing I'm aiming at is disconnecting cibuildwheel releases from Python/PyPy versions. But maybe that just an imaginary problem, though. (But it seems worth thinking about and discussing?)

[Czaki]

I'm not enthusiast of user provided file with download links it may create multiple issue. Main target for this is pypy, but as I remember bumping pypy version often needs some small fix. from my point of view main problem could be old file with pinned download links which becomes outdated.

From the other hand I see profits, But such advanced users may also wrap cibuildwheel in own script which will overwrite get_python_configurations functions.

[YannickJadoul]

It's not only PyPy. It's also the updates to CPython we sometimes have added. The only difference is that the CPython updatesare almost never urgent :-)

[Czaki]

It's not only PyPy. It's also the updates to CPython we sometimes have added. The only difference is that the CPython updatesare almost never urgent :-)

So there is no problem with little longer wait on it until next release which comes from natural development cycle.

I think that next big think for CPython will by 3.10 release.