manics
January 10, 2023, 6:42pm
#1
There’s an issue open on the Repo2docker repository to bump the default Python version from 3.7 (end of life Jun 2023) to 3.10. This will affect https://mybinder.org and anything else using repo2docker.
jupyterhub:main ← yuvipanda:new-default
opened 10:37PM - 18 Nov 22 UTC
3.7 is *quite* old, and folks get caught up in it because it also sometimes forc… es much older versions of packages - and it can be quite confusing to debug (see
https://github.com/2i2c-org/infrastructure/issues/1934) for example.
<!--
Our guide to getting a PR merged https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html#guidelines-to-getting-a-pull-request-merged.
About to propose a big change? Read https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html#process-for-making-a-contribution to maximise the chances of it getting merged quickly.
-->
This will only affect repositories that don’t pin the Python version. If you’ve got any input on whether this is a good or bad idea, or on how best to gather feedback and to communicate this change to others, please feel free to comment on that issue.
There’s a separate issue for long-term planning of other end-of-life dependencies, such as Ubuntu 18.04 (EOL April 2023) which is the current base image in repo2docker:
opened 11:23AM - 21 Nov 22 UTC
needs: discussion
reproducibility
https://github.com/jupyterhub/repo2docker/pull/1219 bumps the default version of… Python, which is a breaking change since it may break repositories that pin package versions that won't work with a newer Python version.
We'll also need to update the base-image from Ubuntu 18.04 soon.
From @betatim
> There is an issue (somewhere :-/) about the fact that for real reproducibility people need to have the triple: repo link, revision of the code and revision of repo2docker. We discussed adding a feature to repo2docker that would allow it to fetch a version of itself and use that instead of what the user installed when building the container (something like fetch the container image for that revision of r2d).
>
> In the past we have broken the "reproducibility promise" a few times already. For example when we switched to jupyter lab as default and I think some, rare, cases.
>
> In general, I think because the universe keeps evolving it is already likely that (very) old revisions of a repo will not build or lead to a container that is quite different. Despite this I think we should try hard not to add to this source of entropy by going wild with breaking changes in r2d.
Related:
- https://github.com/jupyterhub/repo2docker/pull/550
- https://github.com/jupyterhub/repo2docker/issues/487
Again, any input from the communitry is welcome!
1 Like