DOC: summarize current approaches to freezing/reconstructing environments

There exist multiple ways on how to establish a "reproducible" environment. It might be worth documenting them somewhere (e.g., in reproman docs)

Python only

pip freeze/pip install - so requires full installation first, and then freeze. platform "agnostic" (or "arrogant") - no information about about platform/architecture

Conda (primarily Python):

conda list --export > package-list.txt/conda create -n myenv --file package-list.txt

Debian/NeuroDebian

nd_freeze - done once (ahead of time) for a specific date. Could be used to bring back hypothetical past environments (as long as you know which base release and which date). Makes it easy to extend with new packages without breaking reproducibility
nd_freeze_install - helpful to bring back some (exact) past versions of debian packages on existing systems

Platform agnostic:

ReproMan (nd_freeze and nd_freeze_install are pretty much "extracts" of functionality from reproman): trace/install - requires trace (or manual composition) as well. But supports many distributions (debian/neurodebian, conda, virtualenv, VCS (git,svn)).
ReproZip (reproman trace relies on tracing of reprozip) - information is not as detailed, but reprozip provides ability to freeze into a minimal usable image.

GUIX

@kyleam ?

With Guix, freezing comes down to knowing the Guix revision that the package came from (or, more generally, the channel revision that the package came from). This is just the Git revision of the Guix repository.

While Guix allows you to build up a "profile" procedurally/piecemeal (package --install <package>), it's better to generate a profile by writing a manifest that specifies all the packages you want, particularly if you're interested in recreating a profile. Combined with the channel revision, you can use the manifest to reconstruct an environment from a particular revision.

I won't try to do justice to all that you can do with Guix, but here are a few examples to give an idea of what's possible. The easiest way to access an older revision of Guix is guix time-machine. Say that I want to construct a profile from Guix's revision 230e5db71ef53e03aa623940225cc6f0b0f23440 and I have a manifest that looks like this

(use-modules
 (gnu packages))

(packages->manifest
 (map (compose list specification->package+output)
      (list "git"
            "git-annex"
            "git-when-merged")))

The command below will drop into a shell with the paths adjusted so the above packages, as defined by 230e5db71, are available.

guix time-machine --commit=230e5db71 -- \
  environment --manifest=manifest.scm

If you want a bit more isolation, you can unset existing environment variables with environments --pure flag. If you want even more isolation, you can use environments --container flag.

Here's another example that generates a tarball that can be passed to docker load. This image will have the packages from manifest.scm (again, using the package definitions from 230e5db71).

$ guix time-machine --commit=230e5db71 -- \
  pack --format=docker -S /bin=bin --entry-point=bin/git-annex \
  --manifest=manifest.scm
/gnu/store/m5nbi82d5fm9p9hmlpyzz93shazfbwim-docker-pack.tar.gz  # ; generated file
$ docker load </gnu/store/m5nbi82d5fm9p9hmlpyzz93shazfbwim-docker-pack.tar.gz
$ docker run -it --rm git-git-annex-git-when-merged version --raw
7.20191230%

In general, someone using Guix wouldn't likely be interested in creating the Docker image, but it could be useful to share with a someone that doesn't want to use Guix or for use on a system that doesn't have Guix installed.

As I mentioned above, this is a limited description of what Guix offers, but hopefully it helps a bit.

ReproNim / reproman

DOC: summarize current approaches to freezing/reconstructing environments #500