Configuration¶
The beat
command-line utility can operate independently of any initial
configuration. By runig for example the following command:
$ beat dataformats list --remote
By default, beat
is pre-configured to access the main BEAT
website anonymously, but it can be configured to use secret keys for any of
its users and/or access an alternative website installed somewhere else. This
allows users to push modified objects into the platform, completing the
development loop:
Pull objects of interest locally.
Develop new objects or modify existing ones.
Test locally, on an environment similar to the one available at the remote platform. (If the user wants to run the experiment locally without pushing it back to the platform they can use their own environment)
Push back modifications and then scale-up experiment running to explore more databases and more parameter combinations.
In order to properly configure a working prefix and memorize access options on that directory, do the following from your shell:
$ beat config set user myname token thistoken
...
You can verify your username and token have been memorized on that working directory with:
$ beat config show
{
"cache": "cache",
"editor": null,
"platform": "https://www.beat-eu.org/platform/",
"prefix": "/scratch/builds/beat/docs/doc/prefix",
"token": null,
"user": "conda"
}
By default, the command-line program considers the prefix
directory on your
current working directory as your prefix. You can override this setting using the
--prefix
flag:
$ beat --prefix=/Users/myname/work/beat config show
...
Note that it is also possible to set a different code editor
$ beat config set editor vim
So we can imagine using the edit
command to edit locally any object.
For example editing an algorithm named user/integers_echo/1
can be done
using the following command:
$ beat algorithm edit user/integers_echo/1
You can also use the path
command on all your objects to identify all
the files and local paths for any given object.
For example we can get the files path associated with the algorithm
named user/integers_echo/1
using the following command:
$ beat algorithm path user/integers_echo/1
Local Overrides¶
If you use the config set
flag --local
, then the configuration values
are not set on the default configuration file (~/.beatrc
), but instead in
the current working directory (./.beatrc
). Configuration values found
the local directory take precedence over values configured on the global
file. Values from the command-line (such as those passed with --prefix
as
explained above) take precedence over both settings.
You can set a variable on the local directory to override the global settings like this:
# set a different prefix when operating from the current directory
$ beat config set --local prefix `pwd`/other_prefix
$ beat config show
...
Database Root Directories¶
When running an experiment in the BEAT ecosystem using the local
executor (the default executor, also behind the --local
flag), beat
will look into your configuration for any options set by the user that follow
the format database/<db name>/<db version>
. beat
expects that this
option points to a string representing the path to the root folder of the
actual database files for the given database.
For example, the AT&T “Database of Faces” is available on the BEAT platform
as the “atnt” database. The third version of the “atnt” database would be
referenced as “atnt/3”. The object “atnt/3” has a root folder defined on
the BEAT platform already, and changing this locally would mean creating a
new version of the database.
Instead, you may override that path by setting the configuration option
database/atnt/3
to your local path to the database files.
Assuming your username is “user” and you extracted the database files to
~/Downloads/atnt_db
, you can set database/atnt/3
to
/home/user/Downloads/atnt_db
, and BEAT will find the database files.
You may explore different configuration options with the --help
flag of
beat config
:
$ beat config --help
Usage: beat config [OPTIONS] COMMAND [ARGS]...
The manager for beat cmdline configuration.
Options:
-v, --verbose Increase the verbosity level from 0 (only error messages) to
1 (warnings), 2 (log messages), 3 (debug information) by
adding the --verbose option as often as desired (e.g. '-vvv'
for debug).
-?, -h, --help Show this message and exit.
Commands:
get Prints out the contents of a single field.
set Sets the value for a key.
show Shows the configuration.