If r-base is pinned, r-irkernel will resolve to a version that is
compatible with it. But if we pin r-irkernel and not r-base, the
opposite will happen and we will end up with an older version of r-base
than is supported by r-irkernel's modern versions.
I find debugging how versions resolve with conda is really tricky, so
unless we have clear principles of what the pin should be and why, I
strongly advocate we don't have it pinned here.
In this case, having r-irkernel pinned to 1.2 caused us to get stuck at
R version 4.1 instead of going to R 4.2 that is now available.
our logger was never being quite hooked up when not using JSON loggers,
meaning that log messages (such as those fixed here to include newlines) were never shown.
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)
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
- require base env to be a lockfile, environment.yml no longer allowed
- separate `requirements.py-x.y.txt` can be processed post-install, if present
- use this for Python 3.5 env, which has some dependencies only from pip (newer versions than the last py35 build on conda-forge)
use different .lock filename extension, following conda-lock precedent
Could also follow .txt in conda docs!
conda env create -p prefix -f lock.txt *should* work,
but fails with errors about name being required,
but also fails if name is given due to conflict with `-p`
[miniforge](https://github.com/conda-forge/miniforge) is a new
community-led installer that uses conda-forge as the default
channel, rather than defaults. This gives us a few advantages:
- No mixing of defaults & conda-forge channel by default. My
intuition is that this will reduce image size & build times,
but I don't know enough about conda to say if this is real
- It provides installers for architectures unsupported by miniconda.
This is particularly useful important for ARM & PowerPC, when we
want to support those better.
- I like conda-forge, and we should do what we can to support them!
This is a fairly easy, drop-in way to do so
- It is more likely to have newer versions of conda by default
than miniconda
- It provides sha256 hashes for installers rather than just md5. This
makes me personally happy
There should be no user-facing changes here as far as I can tell.
Fixes#858
- get_assemble_files() returns list of files needed for assembly
- if buildpack.assemble_with_subset is set, only load assemble_files
prior to running assembly scripts. Load the rest of the repo afterward
conda opts in to this, but currently I think this works
for everything *except* requirements.txt
pre-commit-ci[bot]