Under Construction

EMAN2 is built with conda-build using binaries from https://anaconda.org, packaged into an installer with constructor as of v2.2.

1. conda is the package manager.

2. https://anaconda.org is the online repository of binaries.

3. conda-build is the tool to build from source.

4. constructor is the tool to package eman2 and dependency binaries into a single installer file.

EMAN2 is distributed as a single installer which includes all its dependencies. However, EMAN2 is not available as a conda-package on https://anaconda.org. In other words it is not possible to install EMAN2 by typing conda install eman2.

Conda

Packages that are available on https://anaconda.org can be installed into any conda environment by issuing the command conda install <package>. Conda installs the package along with its dependencies. In order for packages to benefit from this automation, they need to be packaged in a specific way. That can be done with conda-build. conda-build builds packages according to instructions provided in a recipe. A recipe consists of a file with package metadata, meta.yaml, and any other necessary resources like build scripts, (build.sh, bld.bat), patches and so on.

Recipes, Feedstocks and anaconda.org channel: cryoem

Most of EMAN2 dependencies can be found on anaconda's channels, defaults and conda-forge. A few that do not exist or need to be customized have been built and uploaded to channel cryoem. The recipes are hosted in separate repositories on GitHub. Every recipe repository follows the feedstock approach of conda-forge. See here for a complete list.

Build Strategies

It is possible to utilize conda for building and installing EMAN2 in a few ways. One way is to just install binaries with conda and point to the right locations of dependencies during cmake configuration. Another way is to make use of the newly added features in EMAN2's cmake which find the dependencies automatically. These features are activated only when the build is performed by conda-build. CMake knows the build is a conda-build build only through an environment variable. So, it is possible to set the specific environment variable manually and still activate those features without actually using conda-build. Third way is to use a recipe to run conda-build. Basic instructions for all three strategies follow.

1. Use conda for binaries only

1. Install dependencies

   1. Manually with

      conda install <package>

   2. Or with a single command

      conda install eman-deps -c cryoem -c defaults -c conda-forge

2. Build and install EMAN2 manually into home directory with cmake, make and make install.

3. Resulting installation is under $HOME/EMAN2 by default.

This is detailed on EMAN WIKI. Also, see build_no_envars.sh.

2. Use conda to install EMAN2 into a conda environment

1. Install dependencies

   1. Manually with

      conda install <package>

   2. Or with a single command

      conda install eman-deps -c cryoem -c defaults -c conda-forge

2. Set environment variables.

   export CONDA_BUILD_STATE=BUILD
   export PREFIX=<path-to-anaconda-installation-directory> # $HOME/miniconda2/ or $HOME/anaconda2/
   export SP_DIR=$PREFIX/lib/python2.7/site-packages

3. Build and install EMAN2 manually into conda environment with cmake, make and make install. See build_with_envars.sh.

4. Resulting installation is under Anaconda/Miniconda installation, $HOME/anaconda2/ or $HOME/miniconda2/ by default.

3. Use recipe for a fully automated conda build

conda build <path-to-eman-recipe-directory>
conda install eman2 --use-local -c cryoem -c defaults -c conda-forge

Resulting installation is under Anaconda/Miniconda installation, $HOME/anaconda2/ or $HOME/miniconda2/ by default.

:TODO: Advantages/disadvantages/comparison of the strategies.

Tests

The build strategies described in section Build Strategies are tested on CI (Continuous Integration) servers for MacOSX (TravisCI) and Linux (CircleCI). For Windows (Appveyor), only the recipe strategy is tested. The tests are triggered for every commit that is pushed to GitHub.

Local Build Tests and Automated Daily Snapshot Binaries with Jenkins

:TODO: Jenkins.

Binary Distribution

Constructor

Packaging is done with constructor, a tool for making installers from conda packages. In order to slightly customize the installers the project was forked. The customized project is at https://github.com/cryoem/constructor. The input files for constructor are maintained at https://github.com/cryoem/docker-images https://github.com/cryoem/build-scripts.

The installer has additional tools like conda, conda-build, pip bundled. The installer is setup so that the packages are kept in the installed EMAN2 conda environment cache for convenience.

Build Machines

The binary packages are built on three physical machines. The operating systems are Mac OSX 10.10, CentOS 7 and Windows 10. CentOS 6 binaries are built in a CentOS 6 docker container on the CentOS 7 machine. Various build related scripts are on https://github.com/cryoem/build-scripts.

Cron

:TODO:

Windows

[Windows]

Docker

Docker images and helper scripts are at https://github.com/cryoem/docker-images https://github.com/cryoem/build-scripts.

Command to run docker with GUI support, CentOS7:

xhost + local:root

docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY cryoem/eman-nvidia-cuda8-centos7

:FIXME: Runs as root on Linux. chown doesn't work, the resulting installer has root ownership.

:TODO: More explanation.

:TODO: Review and edit below

Pydusa, OpenMPI and Fftw-mpi

The version of OpenMPI provided with EMAN2 installer may not work with user's batch queueing system, meaning they would not be able to run jobs on more than one node at a time. In that case, installer-provided OpenMPI needs to be removed, pydusa and fftw-mpi need to be installed against OpenMPI that is present in the system. Two scripts, one that uninstalls installer provided OpenMPI, pydusa and fftw-mpi, and another that builds fftw-mpi and pydusa against the system OpenMPI are provided. Instructions [here].

Only OpenMPI is force-removed.

1. So the system or newly installed version is used
2. Force-removing fftw-mpi and, specifically, pydusa leaves the system broken.
3. Even if not removed, later installations overwrite, so there isn't any need to uninstall anyways.