fast-hep/fast-flow

Describe an analysis workflow using YAML

fast-flow's Issues

Support objects as the default backend

At the moment, fast_flow treats the default parameter argument to the main entry-point functions in the __init__.py as a string, due to these lines: https://github.com/FAST-HEP/fast-flow/blob/master/fast_flow/v1/dict_config.py#L45-L46. It would be nice to be able to pass in a class or a module object which is used directly, instead of a string which is imported. All this would require is checking if the "backend" value is a string and only importing it if it is.

Reused stage description doesn't update stage name

This arises from https://github.com/FAST-HEP/fast-flow/blob/master/fast_flow/v1/dict_config.py#L104 not overwriting a value that has been already defined. Since the dictionary for a re-used stage config is the same object.

Improve test coverage

Imported from gitlab issue 1

In particular, since gitlab:!6, we need to improve testing for:

• Test YAML loading code
• Test IMPORT functionality

Add Zenodo badge to README

[![DOI](https://zenodo.org/badge/187254541.svg)](https://zenodo.org/badge/latestdoi/187254541)

or

.. image:: https://zenodo.org/badge/187254541.svg
   :target: https://zenodo.org/badge/latestdoi/187254541

Bring support for auto-documenting stages from fast-carpenter to here

Imported from gitlab issue 2

fast-carpenter!45 is / has added a first attempt at documenting fast-carpenter. Some of the code to self-document the built-in stages could be better placed in this package, which would allow the stage import mechanism to document user-defined stages as well more easily.

Default backend isn't passed through to imported configs

Allow stages without description in the config files

At the moment, all stages need to be described in the yaml, however often a stage might not need configuring. In this case, we currently need people to give an "empty" config, ie an empty dict. This adds clutter to the config files so it would be nice to remove this requirement, possibly having it configurable by the calling code.

Remove support for `this_dir` in import paths

The this_dir approach to specifying import paths is problematic because:

1. It allows for constructions like: /an/absolute/path/{this_dir}/sub/dir/ which wont make much sense
2. It is harder to read and write (since you need quotes around the braces for YAML to be interpreted)
3. The internal handling is a bit more complicated than needs to be

I propose to swap this in favour of absolute paths (which start with a slash) and relative paths (which start with a character other than a slash) and are interpreted as relative to the directory containing the config that is doing the IMPORT.

Update Travis-ci pipeline

• Add auto-deployment to pypi from travis-ci pipeline
• Update the badge in the README to point to travis not the old gitlab pipelines