Skip to content

Feature 2022.02.0 #1

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

Open
wants to merge 123 commits into
base: master
Choose a base branch
from
Open

Feature 2022.02.0 #1

wants to merge 123 commits into from

Conversation

shota-matsumoto-lm
Copy link
Collaborator

No description provided.

yuvipanda and others added 30 commits July 3, 2021 02:09
We get node from the default JupyterLab install, since that
comes from conda-forge. This was not the case when we started -
we installed JupyterLab with pip. We no longer need the nodesource
node.

All the env vars, etc should still work!
Since everything is based off the conda buildpack now,
and that is where we get npm from
PATH doesn't seem to be set at this point to include
the conda environment we just installed?
Earlier, we were depending on it being a dependency
of jupyterlab - I don't think that works anymore.
This just causes a lot of merge conflicts

This reverts commit 6d1dc4a.
updates a bit more than I'd like, but this is the minimum I could find to get node 14 in
We redirect stdout (not stderr) of apt-get update and install
in most other places (check out base.py) to not clutter the
output
Set labels when building image from Dockerfile
packagemanager.rstudio.com is a CRAN mirror provided
by rstudio, with *binary packages* prebuilt for many Linux
Distributions! https://www.rstudio.com/blog/announcing-public-package-manager/
has more excellent detail. It cuts down install times for R packages
by almost 90% in some cases!

Like MRAN (which we use now), they also provide a daily snapshot
of CRAN at that date
(https://docs.rstudio.com/rspm/news/#rstudio-package-manager-2021090).
The URL for CRAN for a particular date can be fetched via an API
call. We call that API, and if there is no snapshot for that date
(anything before Oct 2017), we fall back on to MRAN. Adds a test
to test this fallback.

One possible issue about changing existing binder repos to use binary
builds rather than source builds is that the binary builds sometimes
require you have an apt package installed, and will fail if it is
not. We had to install the zmq library apt package for example -
source installs compile zmq from source, which is where the speedup
comes from. But unlike python wheels or conda packages, these binary
builds are not self-contained - they are linked to apt packages from
the specific distros. So some repos that worked before might fail now.
We can choose a more recent cut-off date to prevent this from happening.
Add command line option to pass extra build args
We were doing this from an old MRAN snapshot. I moved the pin
a little ahead, so IRKernel can also be installed from CRAN
instead of from GitHub. R <= 4.0 gets the old version, and anything
newer gets a more recent version of devtools. This gives us
fast installs for IRkernel with binary packages.

Also add a R 4.0 and R 4.1 test
- Install a different version of RStudio for R < 4.1,
  as latest RStudio doesn't seem to support those. And
  newer RStudio isn't supported on these older R versions.
- Cleanup how Shiny is installed - install it with the same
  apt invocation as rstudio (saves time), and install shiny-proxy
  from PyPI instead or GitHub. The release on PyPI is the same
  as our previous GitHub pin.
- Remove outdated comment about different behavior for R 3.6 - I
  think now we get all our R versions from the same apt repo. Plus,
  the conditional was adding more scripts than just adding extra apt
  package repos
SylvainCorlay and others added 29 commits January 25, 2022 23:58
Delete /tmp/downloaded_packages after running install.R
Without this, you *always* needed a repo2docker_config.py
file to configure anything. This PR makes r2d match the
behavior of most traitlets based applications (like jupyter_server,
jupyterhub, nbconvert, etc)

Fixes jupyterhub#1112
Puts it in the ContainerEngine interface specific to Docker,
so PodMan can implement its own when necessary.

Fixes jupyterhub#711
since Python is removing version string parsing from the standard library

moves Julia-specific semver utilities to top-level
Co-authored-by: Min RK <benjaminrk@gmail.com>
Remove deprecated calls to distutils
- ipywidgets==7.6.5
- jupyter-offlinenotebook==0.2.2
- jupyterlab==3.2.8
Update ipywidgets jupyter-offlinenotebook jupyterlab
bootstrap base env with micromamba
a bit funky, since we are combining two separate parsers
Allow passing in extra args to Docker initialization
Allow passing in traitlets via commandline
installing with Python 3.5 is starting to fail
instead of tmp, since we want it to stick around.
MAMBA_EXE is mamba itself, not micromamba
use variable everywhere, so switching fully to micromamba can happen in once place,
assuming they are fully compatible (they _almost_ are, except for `env update` vs `install` in a couple places)
put micromamba in /usr/local/bin and use mamba for installs
Update Changelog for release 2022.02.0
In order to use podman as a backend for repo2docker (a la https://github.com/manics/repo2podman),
a minimum version of Alpine 3.14 is needed.
[MRG] Update Dockerfile to current Alpine (ALPINE_VERSION=3.15.0)
update Python in some dockerfile tests
[MRG] Pass build_args to `render()` during `--no-build` for consistency with regular builds
shota-matsumoto-lm pushed a commit that referenced this pull request Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.