The PyYAML-4.0 to PyYAML-4.2b1 lack "construct_python_str" which is used
in varianter_yaml_to_mux. Note that 4.0 nor 4.1 were ever released on
pip but they exist in some distributions, therefor it makes sense to
include them here.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The selftests from the main source directory (and package) are already
excluded from being considered modules to be distributed.  Let's also
exclude the tests that have recently been moved to their own modules.

Without this change, the "tests" module will be installed in Python's
library location, and will contain the files from all of those
directories.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

And drop the notion of a "multiplex capable" Avocado.  If the plugin is
installed, then we assume the dependencies have been fulfilled.  The plugin
presence is used then for the creation of the test suite, including the
plugin's own tests.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

New optional plugins are now available, and some in RPM package
format.  Let's include them where plugin RPM packages are listed.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Currently the yaml_to_mux plugin is a core plugin without properly
defined requirements. Let's separate it to optional_plugins, define
dependencies and also build it separately in RPM.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This commit modifies the optional_plugins to depend on VERSION files
located in their main directories and adds "propagate-version" target to
Makefile to update the VERSION files for optional as well as "linkable"
plugins, if VERSION file was present.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Simply because this file won't be available when being installed
from any method outside the source tree.

The downside is obvious: it requires extra steps when doing a new
release.  But that is still better than not being able to ship
these plugins to users using the standard Python mechanisms.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

So users will now be able to find Avocado plugins on PyPI, and install
them via `pip`.  Let's try to be consistent with the naming on those
packages, so that users don't fall into naming traps such as
installing Django related extensions.

Also, those packages map more closely to their (RPM) packaged versions.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Our users have pointed out that the basic Avocado test runner, and its
related packaged form, has too many dependencies.  They're absolutely
right, and the whole goal of having plugins in Avocado is that
dependencies can be made optional according to the features required
by a given user.

This specific change creates three new optional plugins, containing
the extended test runners: remote, vm and docker.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Added version file and updated the respective files

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Now that the avocado package has been given a proper unique name,
that is, avocado-framework, we can define it as a requirement for
external and optional plugins.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This step makes the HTML result a proper Python plugin, by living
outside the Avocado package namespace.

The RPM package is also adjusted: it now builds ands install both
Avocado and the HTML result plugin while keeping the two separate
installable packages.

Developers can use the usual `make link` and `make clean` to enable
and disable all plugins (including this one).
Signed-off-by: NCleber Rosa <crosa@redhat.com>