We want users to be able to install new versions of R
as soon as they are out, without us having to do anything
special in repo2docker. So we can't actually check for 'invalid'
R versions. This is ok, as we don't have to special case apt repos
or similar when installing R from rstudio's debs
r-recommended is a collection of common CRAN packages,
which cause conflicts when trying to install older R.
These same packages can be regular dependencies retrieved from CRAN.
PPA is a specific kind of apt repository, hosted on
launchpad.net. We use https://cran.r-project.org/bin/linux/ubuntu/,
which is just a regular apt repository. The PPA terminology
always confused me, so this just clears that up
- MRAN doesn't seem to have R 4.1 specific snapshots, so let's
default to RSPM for anything 4.1+.
- Otherwise, snapshot dates in 2022 will result in using rspm
- make sure to set PYTHONUNBUFFERED
- implement tee with subprocess readlines
- forward all relevant signals from entrypoint to 'true' command
- add monitor process to ensure child shuts down if parent does (maybe not useful in docker?)
This content provider allows to retrieve the content from a
Software Heritage (SWH) persistent identifier (SWHID).
Typical usage:
repo2docker swh:1:rev:94dca98c006b80309704c717b5d83dff3c1fa3a0
It uses the SWH public vault API to retrieve the content of the given
directory.
Most of the times, this will not need an authentication
token to bypass the rate-limiting of the SWH API.
Without authentication, one should be allowed to retrieve one
directory content per minute.
If this is not enought, then the user must use authenticated calls to
the SWH API.
For this, a new `swh_token` config item has been added to the Repo2Docker
application class.
To use authentication:
repo2docker --config cfg.json swh:1:rev:94dca98c006b80309704c717b5d83dff3c1fa3a0
with the swh_token config option being defined in the cfg.json config file.
Instead of checking that a build which allocates too much memory does
fail, we now only check that we pass the correct arguments to the Docker
API client. It seems reasonable to rely on the docker client working and
doing the right thing. This solves a problem where our CI is flakey
because the kernel of the VM the tests run on doesn't support this.