- removes lockfile copies without version
- enforces that `buildpack.python_version` is always specified (major_pythons['3'] in cases where it could have been falsy before)
- warns when Python version is unspecified, which ensures future reproducibility failures
replaces `.py2` special-case with a general `separate_kernel_env` flag,
currently triggered by requesting Python < 3.7.
Python 3.6 and 3.5 are now treated as Python 2.7
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`