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:

  1. Use the ini-file syntax (a text file); the (default) extension is .cfg

  2. Use a sphinx-style conf.py file (python code – this allows ifs and calculations)

  3. Allow both; where (IDEA) both are read, and the python setting override the ini-file one

Place/Location

  1. The file can be specified as parameter --conf path/to/file.
    Then the below ones will be skipped!

  2. 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 the ATS/path/demo.py can use the config of ATS/path/demo.cfg

  3. 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!

  4. 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

  1. Make an installable pathways package (more or less the pathways-dir)

  2. 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

  3. Documentation; mainly: not in package, nor in WS-bundle. Possible WS and full

GATE/PUT

GATE vs PUTS

The put, the product under test, is typically an address to reach a (one?) thing; the gate is code that abstracts the gate from generic Pathways-code.

So, it kind of wrong the baseclass for the “gate” is “Put”; as are all current subclasses. This should be renamed!

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.