FEATURES (accepted)¶
Note
doc-style
The are written down as documented as if the features already is implemented. They are not, as long they are listed here.
Init/Config file¶
Hint
mostly done
During startup an init/config-file is read; when available. That file can contain global setting, that acts defaults for the parameters that are
normally set as parameter. Like: --gate
, --put
, --log
and --vector
. (But without the dashed).
Those values override the defaults in the ATS, but are overriden by the command-line options.
There are several options¶
Syntax:¶
Use the ini-file syntax (a text file); the (default) extension is .cfg
Use a sphinx-style conf.py file (python code – this allows ifs and calculations)
Allow both; where (IDEA) both are read, and the python setting override the ini-file one
Place/Location¶
The file can be specified as parameter
--conf path/to/file
.
Then the below ones will be skipped!A file with the same (base)name as the ATS-test (typical the ATS-filename), along that ATS-test (so the same dir).
So a ATS in theATS/path/demo.py
can use the config ofATS/path/demo.cfg
The
config.cfg
file in same directory as the ATS-file. This file is only valid for ATS’es in the same dir; an ATS in a subdir will NOT read/use it!The global file
.pathways.cfg
, in the user’s home directory ($HOME
, or its windows equivalent). Alternatively, the directory to find that file can be specified in the environment:PATHWAYS_CONF_DIR
.
When several places are used, the top one override (value by value) the lower one. When the
parameter --conf-only
(with a file; or by the file as set by --conf
) is used,
the other ones are ignored
Todo
Describe the config format: sections, keys and ${key} expansion
The [ATS] section is used (and, the default section)
Note
No ATS/shared.cfg
The idea to have a shared.cfg
file in the ATS/
directory is abandoned.
This ATS-dir (or “top dir”) is only a naming convention; there is no way to calculate (find)
it. It has to be specified; but then, it is useless, not better then using a
--conf
. option
Use ‘$HOME
/.pathways
’ option instead
Auto run ATS¶
Todo
AutoRun ATS_* (Need details)
All ATS-test-functions should have a name that start with ATS_
; (not main as it used to
be).
Then, those tests can be runs automatically (in alphabetic order, by dir/subb/file/func-hierarchy)
Pre/Post¶
Todo
Specify Pre/Post (setup/teardown)
It should be possible to run some code before and after each ATS.
Example: the code in examples/calculators/server/tst/connect_test.py shouldn’t be in a shell-script but (impliciet) in an ATS
split/make package workshop, etc¶
Currently, all of Pathways is one bug development structure. That is too complicated for a workshop. So it has to spilt, or better: ‘distributed’ differently.
Probably the best way is to use make/makefiles to do that; possible some file has to move around
Make an installable pathways package (more or less the pathways-dir)
Make a –or a few– small workshop bundle(s). Both in demo mode and/or practice mode. In ‘demo-mode’ has all (needed) files; in practice-mode, you have make ATS/brick yourself; or extend them
Documentation; mainly: not in package, nor in WS-bundle. Possible WS and full
GATE/PUT¶
Config¶
Put/gate & pathways.core.config.Config
¶
A gate (plugin) should be able to use the config values. This is a feature, but also bug (alike)
E.g the webPut should use a BIN_PATH value to locate the geckodriver
Cmdline gate¶
MultiHead Gate/Put¶
In some cases, it would be very nice to have a gate/put with 2 (or more heads). Eg. to test a (MQTT, DDS, …) channel. Both for functionality and performance.