Go through the following sequence of commands:
$ git checkout https://gitlab.idiap.ch/bob/bob.admin
$ #install miniconda (version 4.4 or above required)
$ conda activate base
$ cd beat.backend.python #cd into this package's sources
$ ../bob.admin/conda/conda-bootstrap.py --overwrite --python=3.6 beat-core-dev
$ conda activate beat-core-dev
$ #n.b.: docker must be installed on your system (see next section)
$ buildout -c develop.cfg
These commands should download and install all non-installed dependencies and get you a fully operational test and development environment.
This package depends on Docker and may use it to run user algorithms in a container with the required software stack. You must install the Docker engine and make sure the user running tests has access to it.
In particular, this package controls memory and CPU utilisation of the containers it launches. You must make sure to enable those functionalities on your installation.
Make sure you have the
docker command available on your system. For certain
operating systems, it is necessary to install
docker via an external
virtual machine (a.k.a. the docker machine). Follow the instructions at the docker website before trying to
execute algorithms or experiments.
We use specific docker images to run user algorithms. Download the following base images before you try to run tests or experiments on your computer:
$ docker pull beatenv/beat.env.db.examples:1.4.1r0
$ docker pull beatenv/beat.env.python:2.1.0r7
$ docker pull beatenv/beat.env.cxxdev:2.0.0r4
$ docker pull beatenv/beat.env.cxx:2.0.0r4
Optionally, you can also download other images to be able to re-run experiments downloaded from the BEAT platform (not required for unit testing). These docker images corresponds to the python environment available on the platform. Keep in mind that at the moment you cannot use different environments to run each block when you are using BEAT locally unless using the Docker executor. These images can be found on the beatenv docker hub repository.
Before pulling these images, you should check the registry as there might have been new release (i.e. rX versions).
To run an experiment using docker you should specify the docker image when defining the experiment, then use the –docker flag when using beat.cmdline:
$ beat experiment run --docker <experiment name>
You can find more information about running experiments locally using different executors in the “Experiments” section of “beat.cmdline” in BEAT documentation.
Custom image development¶
Scientific development evolving quickly, the platform provided runtime environments may not contain everything you need for your algorithms to run. In that case, you can prepare your own environment using the following git repository.
$ git clone https://gitlab.idiap.ch/beat/beat.env.example
The examples provided there will allow you to build docker images suitable both for algorithm execution and if needed database handling.
Instructions are provided in the repository.
To build the documentation, just do:
$ ./bin/sphinx-build doc sphinx
After installation, it is possible to run our suite of unit tests. To do so,
$ ./bin/nosetests -sv
Some of the tests for our command-line toolkit require a running BEAT
platform web-server, with a compatible
beat.core installed (preferably
the same). By default, these tests will be skipped. If you want to run
them, you must setup a development web server and set the environment
BEAT_CORE_TEST_PLATFORM to point to that address. For example:
$ export BEAT_CORE_TEST_PLATFORM="http://example.com/platform/"
$ ./bin/nosetests -sv
Do NOT run tests against a production web server.
If you want to skip slow tests (at least those pulling stuff from our servers) or executing lengthy operations, just do:
$ ./bin/nosetests -sv -a '!slow'
To measure the test coverage, do the following:
$ ./bin/nosetests -sv --with-coverage --cover-package=beat.core
Our documentation is also interspersed with test units. You can run them using sphinx:
$ ./bin/sphinx -b doctest doc sphinx
In order to profile the test code, try the following:
$ ./bin/python -mcProfile -oprof.data ./bin/nosetests -sv ...
This will dump the profiling data at
prof.data. You can dump its contents
in different ways using another command:
$ ./bin/python -mpstats prof.data
This will allow you to dump and print the profiling statistics as you may find fit.