Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump default python version to 3.7 #539

Merged
merged 4 commits into from Feb 21, 2019
Merged

Bump default python version to 3.7 #539

merged 4 commits into from Feb 21, 2019

Conversation

@yuvipanda
Copy link
Collaborator

@yuvipanda yuvipanda commented Dec 24, 2018

No description provided.

@betatim
Copy link
Member

@betatim betatim commented Dec 24, 2018

#533 might be relevant and there is another issue (or PR) where we discuss what "LTS" means in terms of the default Python version.

@yuvipanda
Copy link
Collaborator Author

@yuvipanda yuvipanda commented Dec 24, 2018

@betatim that issue is around RStudio. Did you mean #521? That mentions LTS.

I think #521 is unrelated, since it's about what version of python the repo2docker code should support, rather than the default for images built with repo2docker.

@betatim
Copy link
Member

@betatim betatim commented Dec 26, 2018

Yes I think I meant #521. Not sure why I wrote 533. Looking now I might have meant #522 and the discussion about what the default version of Python is that will be installed in a conda environment.

I think the discussion in #521 is related despite it being about the version of Python required to run r2d. We should make some promises about which version of Python ends up in an image by default. I consider the version of the tools we install part of what we version. Similar to a library that versions its API and default arguments etc.

I don't know what our strategy should be but I do think we should decide on a strategy and write it down so that users can rely on it and plan accordingly.

@yuvipanda
Copy link
Collaborator Author

@yuvipanda yuvipanda commented Jan 21, 2019

Picking back up on this, I'd say the smallest thing we can say is that 'bumping default versions means we bump repo2docker version too'. This also ties back into writing a 'repo2docker spec' that will specify the default language versions (along with how each file is interpreted).

For now, I'd say bumping the version means we've to make a new release. How does that sound, @betatim and @minrk?

@minrk
Copy link
Member

@minrk minrk commented Jan 21, 2019

I think that's sensible. Bumping the default minor version of Python would be a major version upgrade for repo2docker.

@yuvipanda yuvipanda force-pushed the yuvipanda:v3.7 branch to d8f8c78 Feb 11, 2019
@yuvipanda
Copy link
Collaborator Author

@yuvipanda yuvipanda commented Feb 11, 2019

Updated, let's see if things pass

@betatim
Copy link
Member

@betatim betatim commented Feb 12, 2019

I'm still hesitant to bump the default version of Python. Most research code lags behind by a country mile, people might not have pinned the version of Python they want and we don't yet have support to pin repo2docker versions for a repo. Mostly I am worried about breaking user's repos that used to work but now don't anymore.

Compromise: we bump the Python version and add a note/new section/howto in the docs that explains how to pin the version of Python (runtime.txt or environment.yml) that we can send people to that will come because we broke stuff: look this is how you pin it which is a good idea anyway and will un-break you. WDY?

@yuvipanda
Copy link
Collaborator Author

@yuvipanda yuvipanda commented Feb 13, 2019

@betatim Sounds like a good idea to me. Where do you think that should live?

I see https://mybinder.readthedocs.io/en/latest/config_files.html#runtime-txt-specifying-runtimes now...

@betatim
Copy link
Member

@betatim betatim commented Feb 13, 2019

I think I'd put it in the repo2docker docs (and link from the binder docs?)

There is already https://repo2docker.readthedocs.io/en/latest/howto/languages.html#specifying-a-version-of-python so maybe adding a FAQ with a title that speaks to people who are grumpy because their stuff just broke like: "How to select the version of Python used?" or "How should I freeze the version of Python used?" or some such that points to that section is enough.


We should try and (re)organise our various documentations? I always feel lost in them, especially what is/should be where.

@yuvipanda
Copy link
Collaborator Author

@yuvipanda yuvipanda commented Feb 20, 2019

Given my current situation, I'm trying to minimize typing where I can. Would be lovely if someone other than me could get the doc bit in. Thanks.

minrk added 2 commits Feb 21, 2019
and get docs version from the package so it doesn't get out of date
- clarify that runtime.txt is only for env files that don't support runtime specification
- specify default version of Python and when it changed
- more links to pinning docs
@minrk
Copy link
Member

@minrk minrk commented Feb 21, 2019

Updated some docs on pinning runtime. I think we already had everything being asked for, I just updated the language a bit and added a reference to the default version that's pulled from the code so it'll always be correct.

  • FAQ already has how to pin Python as the first two Qs, it is also mentioned in config_files and the Python section of howto/languages. Added some detail about which version is default and links to config_files
  • clarification in a few places that runtime.txt is only for use with environment specifications that do not support specifying the runtime (i.e. only with requirements.txt, not environment.yml)
  • get default Python version from the code so that it's harder to fall out of date

What I didn't do is add a whole new section on best practices on pinning because I think this is pretty nuanced and not a last-minute thing to do for release (the worst thing you can do is strictly pin only some dependencies, e.g. a requirements.txt that looks like):

numpy==1.15.3

without pinning Python as well, or with other unpinned packages, e.g. just matplotlib.

It's better to either:

  • loosely specify all requirements, including Python, to ensure you get the most compatible latest combination of everything, or
  • strictly specify all requirements and all their dependencies, including Python, to ensure you get a known-good combination frozen in time.
@betatim betatim merged commit 397695b into jupyterhub:master Feb 21, 2019
4 of 5 checks passed
4 of 5 checks passed
codecov/patch 0% of diff hit (target 20%)
Details
ci/circleci: build_docs Your tests passed on CircleCI!
Details
ci/dockercloud Your tests passed in Docker Cloud
Details
codecov/project 86.81% (+0.11%) compared to 9766c95
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@betatim
Copy link
Member

@betatim betatim commented Feb 21, 2019

Thanks!

@yuvipanda
Copy link
Collaborator Author

@yuvipanda yuvipanda commented Feb 21, 2019

Thank you very much, @minrk and @betatim!

@yuvipanda yuvipanda deleted the yuvipanda:v3.7 branch Feb 21, 2019
markmo pushed a commit to markmo/repo2docker that referenced this pull request Jan 22, 2021
Bump default python version to 3.7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants