Add an environment variable during the build process.

Proposed change

I’d like to see an environment variable to the tune of REPO2DOCKER=1 (or maybe just the current version of repo2docker?). The reason for this is to enable some specific setup for a Julia package if it’s being built as part of repo2docker, specifically for Binder (see this GitHub issue for more context).

Alternative options

Status quo.

Who would use this feature?

How much effort will adding it take?

All of about twenty seconds (add a line to the base buildpack class).

Who can do this work?

I’m happy to make a PR if this sounds okay.

[betatim]

I’m not mad keen. I think asking users to install the extension explicitly is more in line with our goal of trying to reduce the amount of magic/special casing. The goal of repo2docker is to automate best practices (not invent new ones). One thing this means is that we’d want it to be possible for someone to look at a repo that repo2docker can build and more or less quickly figure out what commands they’d have to type by hand to achieve the same goal. Packages/installers behaving differently when run inside a docker build by repo2docker (but not other docker builds) seems counter to that desire. So I think it would be better to require people to install the extension explicitly via a postBuild. This is a common pattern for other notebook extensions. The other common pattern is that installing the extensions package also installs the extension.

What do you think?

[travigd]

One thing that will make this trickier is that you need to find a balance between making the env variable available early enough to build steps but late enough so that you only invalidate the cache that actually needs invalidating (just because the version of repo2docker has changed doesn’t mean a large number of layers have become invalid).

That’s a great point! I only suggested the version as the value so that it’s semantically meaningful, but it might make more sense to just set it equal to 1 (kind of like how you have CI=1 in CI environments) and not expose the version for exactly that cache invalidation problem. Another solution might just be to have minor versions (e.g. 1.2 instead of 1.2.3) since that changes less often.

Otherwise, I think the latest it could be set (and still work for my own personal goals) is right before installing packages.