yaml_to_mux: Turn yaml_to_mux plugin to optional one

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>

docs/source/conf.py

@@ -115,9 +115,7 @@ with open(os.path.join(api_optional_plugins_path, "index.rst"),
 Optional Plugins API
 ====================
 
-The following pages are auto-generated API documentation of optional
-Avocado plugins. This is not public API, it represents only current
-version and can be changed any time.
+The following pages document the private APIs of optional Avocado plugins.
 
 .. toctree::
    :maxdepth: 1

docs/source/optional_plugins/index.rst

@@ -12,3 +12,4 @@ optional plugins:
 
    results
    robot
+   varianter_yaml_to_mux

docs/source/optional_plugins/varianter_yaml_to_mux.rst

+.. _yaml-to-mux-plugin:
+
+Yaml_to_mux plugin
+==================
+
+:mod:`avocado_varianter_yaml_to_mux`
+
+This plugin utilizes the in-core ``multiplexation`` mechanism to
+produce variants out of a yaml file. This section is example-based,
+if you are interested in test parameters and/or ``multiplexation``
+overview, please take a look at :ref:`test-parameters`.
+
+As mentioned earlier, it inherits from the
+:class:`avocado.core.mux.MuxPlugin` and the only thing it implements
+is the argument parsing to get some input and a custom ``yaml``
+parser (which is also capable of parsing ``json``).
+
+The ``yaml`` file is perfect for this task as it's easily read by
+both, humans and machines.  Let's start with an example (line
+numbers at the first columns are for documentation purposes only,
+they are not part of the multiplex file format):
+
+.. code-block:: yaml
+
+     1  hw:
+     2      cpu: !mux
+     3          intel:
+     4              cpu_CFLAGS: '-march=core2'
+     5          amd:
+     6              cpu_CFLAGS: '-march=athlon64'
+     7          arm:
+     8              cpu_CFLAGS: '-mabi=apcs-gnu -march=armv8-a -mtune=arm8'
+     9      disk: !mux
+    10          scsi:
+    11              disk_type: 'scsi'
+    12          virtio:
+    13              disk_type: 'virtio'
+    14  distro: !mux
+    15      fedora:
+    16          init: 'systemd'
+    17      mint:
+    18          init: 'systemv'
+    19  env: !mux
+    20      debug:
+    21          opt_CFLAGS: '-O0 -g'
+    22      prod:
+    23          opt_CFLAGS: '-O2'
+
+
+.. warning:: On some architectures misbehaving versions of CYaml
+   Python library were reported and Avocado always fails with
+   ``unacceptable character #x0000: control characters are not
+   allowed``. To workaround this issue you need to either update
+   the PyYaml to the version which works properly, or you need
+   to remove the ``python2.7/site-packages/yaml/cyaml.py`` or
+   disable CYaml import in Avocado sources. For details check
+   out the `Github issue <https://github.com/avocado-framework/avocado/issues/1190>`_
+
+There are couple of key=>value pairs (lines 4,6,8,11,13,...) and there are
+named nodes which define scope (lines 1,2,3,5,7,9,...). There are also additional
+flags (lines 2, 9, 14, 19) which modifies the behavior.
+
+
+Nodes
+-----
+
+They define context of the key=>value pairs allowing us to easily identify
+for what this values might be used for and also it makes possible to define
+multiple values of the same keys with different scope.
+
+Due to their purpose the YAML automatic type conversion for nodes names
+is disabled, so the value of node name is always as written in the yaml
+file (unlike values, where `yes` converts to `True` and such).
+
+Nodes are organized in parent-child relationship and together they create
+a tree. To view this structure use ``avocado variants --tree -m <file>``::
+
+ ┗━━ run
+      ┣━━ hw
+      ┃    ┣━━ cpu
+      ┃    ┃    ╠══ intel
+      ┃    ┃    ╠══ amd
+      ┃    ┃    ╚══ arm
+      ┃    ┗━━ disk
+      ┃         ╠══ scsi
+      ┃         ╚══ virtio
+      ┣━━ distro
+      ┃    ╠══ fedora
+      ┃    ╚══ mint
+      ┗━━ env
+           ╠══ debug
+           ╚══ prod
+
+You can see that ``hw`` has 2 children ``cpu`` and ``disk``. All parameters
+defined in parent node are inherited to children and extended/overwritten by
+their values up to the leaf nodes. The leaf nodes (``intel``, ``amd``, ``arm``,
+``scsi``, ...) are the most important as after multiplexation they form the
+parameters available in tests.
+
+
+Keys and Values
+---------------
+
+Every value other than dict (4,6,8,11) is used as value of the antecedent
+node.
+
+Each node can define key/value pairs (lines 4,6,8,11,...). Additionally
+each children node inherits values of it's parent and the result is called
+node ``environment``.
+
+Given the node structure bellow:
+
+.. code-block:: yaml
+
+    devtools:
+        compiler: 'cc'
+        flags:
+            - '-O2'
+        debug: '-g'
+        fedora:
+            compiler: 'gcc'
+            flags:
+                - '-Wall'
+        osx:
+            compiler: 'clang'
+            flags:
+                - '-arch i386'
+                - '-arch x86_64'
+
+And the rules defined as:
+
+* Scalar values (Booleans, Numbers and Strings) are overwritten by walking from the root until the final node.
+* Lists are appended (to the tail) whenever we walk from the root to the final node.
+
+The environment created for the nodes ``fedora`` and ``osx`` are:
+
+- Node ``//devtools/fedora`` environment ``compiler: 'gcc'``, ``flags: ['-O2', '-Wall']``
+- Node ``//devtools/osx`` environment ``compiler: 'clang'``, ``flags: ['-O2', '-arch i386', '-arch x86_64']``
+
+Note that due to different usage of key and values in environment we disabled
+the automatic value conversion for keys while keeping it enabled for values.
+This means that the value can be of any YAML supported value, eg. bool, None,
+list or custom type, while the key is always string.
+
+Variants
+--------
+
+In the end all leaves are gathered and turned into parameters, more specifically into
+``AvocadoParams``:
+
+.. code-block:: yaml
+
+    setup:
+        graphic:
+            user: "guest"
+            password: "pass"
+        text:
+            user: "root"
+            password: "123456"
+
+produces ``[graphic, text]``. In the test code you'll be able to query only
+those leaves. Intermediary or root nodes are available.
+
+The example above generates a single test execution with parameters separated
+by path. But the most powerful multiplexer feature is that it can generate
+multiple variants. To do that you need to tag a node whose children are
+ment to be multiplexed. Effectively it returns only leaves of one child at the
+time.In order to generate all possible variants multiplexer creates cartesian
+product of all of these variants:
+
+.. code-block:: yaml
+
+    cpu: !mux
+        intel:
+        amd:
+        arm:
+    fmt: !mux
+        qcow2:
+        raw:
+
+Produces 6 variants::
+
+    /cpu/intel, /fmt/qcow2
+    /cpu/intel, /fmt/raw
+    ...
+    /cpu/arm, /fmt/raw
+
+The !mux evaluation is recursive so one variant can expand to multiple
+ones:
+
+.. code-block:: yaml
+
+    fmt: !mux
+        qcow: !mux
+            2:
+            2v3:
+        raw:
+
+Results in::
+
+    /fmt/qcow2/2
+    /fmt/qcow2/2v3
+    /raw
+
+
+.. _yaml-to-mux-resolution-order:
+
+Resolution order
+----------------
+
+You can see that only leaves are part of the test parameters. It might happen
+that some of these leaves contain different values of the same key. Then
+you need to make sure your queries separate them by different paths. When
+the path matches multiple results with different origin, an exception is raised
+as it's impossible to guess which key was originally intended.
+
+To avoid these problems it's recommended to use unique names in test parameters if
+possible, to avoid the mentioned clashes. It also makes it easier to extend or mix
+multiple YAML files for a test.
+
+For multiplex YAML files that are part of a framework, contain default
+configurations, or serve as plugin configurations and other advanced setups it is
+possible and commonly desirable to use non-unique names. But always keep those points
+in mind and provide sensible paths.
+
+Multiplexer also supports default paths. By default it's ``/run/*`` but it can
+be overridden by ``--mux-path``, which accepts multiple arguments. What it does
+it splits leaves by the provided paths. Each query goes one by one through
+those sub-trees and first one to hit the match returns the result. It might not
+solve all problems, but it can help to combine existing YAML files with your
+ones:
+
+.. code-block:: yaml
+
+    qa:         # large and complex read-only file, content injected into /qa
+        tests:
+            timeout: 10
+        ...
+    my_variants: !mux        # your YAML file injected into /my_variants
+        short:
+            timeout: 1
+        long:
+            timeout: 1000
+
+You want to use an existing test which uses ``params.get('timeout', '*')``.  Then you
+can use ``--mux-path '/my_variants/*' '/qa/*'`` and it'll first look in your
+variants. If no matches are found, then it would proceed to ``/qa/*``
+
+Keep in mind that only slices defined in mux-path are taken into account for
+relative paths (the ones starting with ``*``)
+
+
+Injecting files
+---------------
+
+You can run any test with any YAML file by::
+
+    avocado run sleeptest.py --mux-yaml file.yaml
+
+This puts the content of ``file.yaml`` into ``/run``
+location, which as mentioned in previous section, is the default ``mux-path``
+path. For most simple cases this is the expected behavior as your files
+are available in the default path and you can safely use ``params.get(key)``.
+
+When you need to put a file into a different location, for example
+when you have two files and you don't want the content to be merged into
+a single place becoming effectively a single blob, you can do that by
+giving a name to your yaml file::
+
+    avocado run sleeptest.py --mux-yaml duration:duration.yaml
+
+The content of ``duration.yaml`` is injected into ``/run/duration``. Still when
+keys from other files don't clash, you can use ``params.get(key)`` and retrieve
+from this location as it's in the default path, only extended by the
+``duration`` intermediary node. Another benefit is you can merge or separate
+multiple files by using the same or different name, or even a complex
+(relative) path.
+
+Last but not least, advanced users can inject the file into whatever location
+they prefer by::
+
+    avocado run sleeptest.py --mux-yaml /my/variants/duration:duration.yaml
+
+Simple ``params.get(key)`` won't look in this location, which might be the
+intention of the test writer. There are several ways to access the values:
+
+* absolute location ``params.get(key, '/my/variants/duration')``
+* absolute location with wildcards ``params.get(key, '/my/*)``
+  (or ``/*/duration/*``...)
+* set the mux-path ``avocado run ... --mux-path /my/*`` and use relative path
+
+It's recommended to use the simple injection for single YAML files, relative
+injection for multiple simple YAML files and the last option is for very
+advanced setups when you either can't modify the YAML files and you need to
+specify custom resolution order or you are specifying non-test parameters, for
+example parameters for your plugin, which you need to separate from the test
+parameters.
+
+
+Multiple files
+--------------
+
+You can provide multiple files. In such scenario final tree is a combination
+of the provided files where later nodes with the same name override values of
+the preceding corresponding node. New nodes are appended as new children:
+
+.. code-block:: yaml
+
+    file-1.yaml:
+        debug:
+            CFLAGS: '-O0 -g'
+        prod:
+            CFLAGS: '-O2'
+
+    file-2.yaml:
+        prod:
+            CFLAGS: '-Os'
+        fast:
+            CFLAGS: '-Ofast'
+
+results in:
+
+.. code-block:: yaml
+
+    debug:
+        CFLAGS: '-O0 -g'
+    prod:
+        CFLAGS: '-Os'       # overriden
+    fast:
+        CFLAGS: '-Ofast'    # appended
+
+It's also possible to include existing file into another a given node in another
+file. This is done by the `!include : $path` directive:
+
+.. code-block:: yaml
+
+    os:
+        fedora:
+            !include : fedora.yaml
+        gentoo:
+            !include : gentoo.yaml
+
+.. warning:: Due to YAML nature, it's **mandatory** to put space between
+             `!include` and the colon (`:`) that must follow it.
+
+The file location can be either absolute path or relative path to the YAML
+file where the `!include` is called (even when it's nested).
+
+Whole file is **merged** into the node where it's defined.
+
+
+Advanced YAML tags
+------------------
+
+There are additional features related to YAML files. Most of them require values
+separated by ``":"``. Again, in all such cases it's mandatory to add a white space
+(``" "``) between the tag and the ``":"``, otherwise ``":"`` is part of the tag
+name and the parsing fails.
+
+!include
+^^^^^^^^
+
+Includes other file and injects it into the node it's specified in:
+
+.. code-block:: yaml
+
+    my_other_file:
+        !include : other.yaml
+
+The content of ``/my_other_file`` would be parsed from the ``other.yaml``. It's
+the hardcoded equivalent of the ``-m $using:$path``.
+
+Relative paths start from the original file's directory.
+
+!using
+^^^^^^
+
+Prepends path to the node it's defined in:
+
+.. code-block:: yaml
+
+    !using : /foo
+    bar:
+        !using : baz
+
+``bar`` is put into ``baz`` becoming ``/baz/bar`` and everything is put into
+``/foo``. So the final path of ``bar`` is ``/foo/baz/bar``.
+
+!remove_node
+^^^^^^^^^^^^
+
+Removes node if it existed during the merge. It can be used to extend
+incompatible YAML files:
+
+.. code-block:: yaml
+
+    os:
+        fedora:
+        windows:
+            3.11:
+            95:
+    os:
+        !remove_node : windows
+        windows:
+            win3.11:
+            win95:
+
+Removes the `windows` node from structure. It's different from `filter-out`
+as it really removes the node (and all children) from the tree and
+it can be replaced by you new structure as shown in the example. It removes
+`windows` with all children and then replaces this structure with slightly
+modified version.
+
+As `!remove_node` is processed during merge, when you reverse the order,
+windows is not removed and you end-up with `/windows/{win3.11,win95,3.11,95}`
+nodes.
+
+!remove_value
+^^^^^^^^^^^^^
+
+It's similar to `!remove_node`_ only with values.
+
+!mux
+^^^^
+
+Children of this node will be multiplexed. This means that in first variant
+it'll return leaves of the first child, in second the leaves of the second
+child, etc. Example is in section `Variants`_
+
+!filter-only
+------------
+
+Defines internal filters. They are inherited by children and evaluated
+during multiplexation. It allows one to specify the only compatible branch
+of the tree with the current variant, for example::
+
+    cpu:
+        arm:
+            !filter-only : /disk/virtio
+    disk:
+        virtio:
+        scsi:
+
+will skip the ``[arm, scsi]`` variant and result only in ``[arm, virtio]``
+
+_Note: It's possible to use ``!filter-only`` multiple times with the same
+parent and all allowed variants will be included (unless they are
+filtered-out by ``!filter-out``)_
+
+_Note2: The evaluation order is 1. filter-out, 2. filter-only. This means when
+you booth filter-out and filter-only a branch it won't take part in the
+multiplexed variants._
+
+!filter-out
+-----------
+
+Similarly to `!filter-only`_ only it skips the specified branches and leaves
+the remaining ones. (in the same example the use of
+``!filter-out : /disk/scsi`` results in the same behavior). The difference
+is when a new disk type is introduced, ``!filter-only`` still allows just
+the specified variants, while ``!filter-out`` only removes the specified
+ones.
+
+As for the speed optimization, currently Avocado is strongly optimized
+towards fast ``!filter-out`` so it's highly recommended using them
+rather than ``!filter-only``, which takes significantly longer to
+process.
+
+Complete example
+----------------
+
+Let's take a second look at the first example::
+
+     1    hw:
+     2        cpu: !mux
+     3            intel:
+     4                cpu_CFLAGS: '-march=core2'
+     5            amd:
+     6                cpu_CFLAGS: '-march=athlon64'
+     7            arm:
+     8                cpu_CFLAGS: '-mabi=apcs-gnu -march=armv8-a -mtune=arm8'
+     9        disk: !mux
+    10            scsi:
+    11                disk_type: 'scsi'
+    12            virtio:
+    13                disk_type: 'virtio'
+    14    distro: !mux
+    15        fedora:
+    16            init: 'systemd'
+    17        mint:
+    18            init: 'systemv'
+    19    env: !mux
+    20        debug:
+    21            opt_CFLAGS: '-O0 -g'
+    22        prod:
+    23            opt_CFLAGS: '-O2'
+
+After filters are applied (simply removes non-matching variants), leaves
+are gathered and all variants are generated::
+
+    $ avocado variants -m examples/mux-environment.yaml
+    Variants generated:
+    Variant 1:    /hw/cpu/intel, /hw/disk/scsi, /distro/fedora, /env/debug
+    Variant 2:    /hw/cpu/intel, /hw/disk/scsi, /distro/fedora, /env/prod
+    Variant 3:    /hw/cpu/intel, /hw/disk/scsi, /distro/mint, /env/debug
+    Variant 4:    /hw/cpu/intel, /hw/disk/scsi, /distro/mint, /env/prod
+    Variant 5:    /hw/cpu/intel, /hw/disk/virtio, /distro/fedora, /env/debug
+    Variant 6:    /hw/cpu/intel, /hw/disk/virtio, /distro/fedora, /env/prod
+    Variant 7:    /hw/cpu/intel, /hw/disk/virtio, /distro/mint, /env/debug
+    Variant 8:    /hw/cpu/intel, /hw/disk/virtio, /distro/mint, /env/prod
+    Variant 9:    /hw/cpu/amd, /hw/disk/scsi, /distro/fedora, /env/debug
+    Variant 10:    /hw/cpu/amd, /hw/disk/scsi, /distro/fedora, /env/prod
+    Variant 11:    /hw/cpu/amd, /hw/disk/scsi, /distro/mint, /env/debug
+    Variant 12:    /hw/cpu/amd, /hw/disk/scsi, /distro/mint, /env/prod
+    Variant 13:    /hw/cpu/amd, /hw/disk/virtio, /distro/fedora, /env/debug
+    Variant 14:    /hw/cpu/amd, /hw/disk/virtio, /distro/fedora, /env/prod
+    Variant 15:    /hw/cpu/amd, /hw/disk/virtio, /distro/mint, /env/debug
+    Variant 16:    /hw/cpu/amd, /hw/disk/virtio, /distro/mint, /env/prod
+    Variant 17:    /hw/cpu/arm, /hw/disk/scsi, /distro/fedora, /env/debug
+    Variant 18:    /hw/cpu/arm, /hw/disk/scsi, /distro/fedora, /env/prod
+    Variant 19:    /hw/cpu/arm, /hw/disk/scsi, /distro/mint, /env/debug
+    Variant 20:    /hw/cpu/arm, /hw/disk/scsi, /distro/mint, /env/prod
+    Variant 21:    /hw/cpu/arm, /hw/disk/virtio, /distro/fedora, /env/debug
+    Variant 22:    /hw/cpu/arm, /hw/disk/virtio, /distro/fedora, /env/prod
+    Variant 23:    /hw/cpu/arm, /hw/disk/virtio, /distro/mint, /env/debug
+    Variant 24:    /hw/cpu/arm, /hw/disk/virtio, /distro/mint, /env/prod
+
+Where the first variant contains::
+
+    /hw/cpu/intel/  => cpu_CFLAGS: -march=core2
+    /hw/disk/       => disk_type: scsi
+    /distro/fedora/ => init: systemd
+    /env/debug/     => opt_CFLAGS: -O0 -g
+
+The second one::
+
+    /hw/cpu/intel/  => cpu_CFLAGS: -march=core2
+    /hw/disk/       => disk_type: scsi
+    /distro/fedora/ => init: systemd
+    /env/prod/      => opt_CFLAGS: -O2
+
+From this example you can see that querying for ``/env/debug`` works only in
+the first variant, but returns nothing in the second variant. Keep this in mind
+and when you use the ``!mux`` flag always query for the pre-mux path,
+``/env/*`` in this example.

optional_plugins/varianter_yaml_to_mux/MANIFEST.in

+include VERSION

optional_plugins/varianter_yaml_to_mux/VERSION

+50.0

avocado/plugins/yaml_to_mux.py → optional_plugins/varianter_yaml_to_mux/avocado_varianter_yaml_to_mux/__init__.py

@@ -9,9 +9,9 @@
 #
 # See LICENSE for more details.
 #
-# Copyright: Red Hat Inc. 2016
+# Copyright: Red Hat Inc. 2016-2017
 # Author: Lukas Doktor <ldoktor@redhat.com>
-"""Multiplexer plugin to parse yaml files to params"""
+"""Varianter plugin to parse yaml files to params"""
 
 import copy
 import os
@@ -279,7 +279,7 @@ class YamlToMuxCLI(CLI):
 
     def configure(self, parser):
         """
-        Configures "run" and "multiplex" subparsers
+        Configures "run" and "variants" subparsers
         """
         if not MULTIPLEX_CAPABLE:
             return

optional_plugins/varianter_yaml_to_mux/setup.py

+#!/bin/env python
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+#
+# See LICENSE for more details.
+#
+# Copyright: Red Hat Inc. 2017
+# Author: Cleber Rosa <crosa@redhat.com>
+
+from setuptools import setup, find_packages
+
+
+setup(name='avocado-framework-plugin-varianter-yaml-to-mux',
+      description='Avocado Varianter plugin to parse yaml file into variants',
+      version=open("VERSION", "r").read().strip(),
+      author='Avocado Developers',
+      author_email='avocado-devel@redhat.com',
+      url='http://avocado-framework.github.io/',
+      packages=find_packages(),
+      include_package_data=True,
+      install_requires=['avocado-framework', 'PyYAML'],
+      entry_points={
+          "avocado.plugins.cli": [
+              "yaml_to_mux = avocado_varianter_yaml_to_mux:YamlToMuxCLI",
+          ],
+          "avocado.plugins.varianter": [
+              "yaml_to_mux = avocado_varianter_yaml_to_mux:YamlToMux"]})

python-avocado.spec

@@ -29,7 +29,7 @@
 Summary: Framework with tools and libraries for Automated Testing
 Name: python-%{srcname}
 Version: 50.0
-Release: 0%{?gitrel}%{?dist}
+Release: 1%{?gitrel}%{?dist}
 License: GPLv2
 Group: Development/Tools
 URL: http://avocado-framework.github.io/
@@ -52,7 +52,6 @@ BuildRequires: python-resultsdb_api
 BuildRequires: python-setuptools
 BuildRequires: python-sphinx
 BuildRequires: python-stevedore
-BuildRequires: python-yaml
 BuildRequires: python2-devel
 BuildRequires: yum
 
@@ -69,7 +68,6 @@ Requires: python
 Requires: python-requests
 Requires: python-setuptools
 Requires: python-stevedore
-Requires: python-yaml
 %if 0%{?fedora}
 BuildRequires: python-aexpect
 %else
@@ -133,6 +131,9 @@ popd
 pushd optional_plugins/resultsdb
 %{__python} setup.py build
 popd
+pushd optional_plugins/varianter_yaml_to_mux
+%{__python} setup.py build
+popd
 %{__make} man
 
 %install
@@ -152,6 +153,9 @@ popd
 pushd optional_plugins/resultsdb
 %{__python} setup.py install --root %{buildroot} --skip-build
 popd
+pushd optional_plugins/varianter_yaml_to_mux
+%{__python} setup.py install --root %{buildroot} --skip-build
+popd
 %{__mkdir} -p %{buildroot}%{_mandir}/man1
 %{__install} -m 0644 man/avocado.1 %{buildroot}%{_mandir}/man1/avocado.1
 %{__install} -m 0644 man/avocado-rest-client.1 %{buildroot}%{_mandir}/man1/avocado-rest-client.1
@@ -175,6 +179,9 @@ popd
 pushd optional_plugins/resultsdb
 %{__python} setup.py develop --user
 popd
+pushd optional_plugins/varianter_yaml_to_mux
+%{__python} setup.py develop --user
+popd
 # Package build environments have the least amount of resources
 # we have observed so far.  Let's avoid tests that require too
 # much resources or are time sensitive
@@ -210,11 +217,13 @@ AVOCADO_CHECK_LEVEL=0 selftests/run
 %exclude %{python_sitelib}/avocado_runner_vm*
 %exclude %{python_sitelib}/avocado_runner_docker*
 %exclude %{python_sitelib}/avocado_resultsdb*
+%exclude %{python_sitelib}/avocado_varianter_yaml_to_mux*
 %exclude %{python_sitelib}/avocado_framework_plugin_result_html*
 %exclude %{python_sitelib}/avocado_framework_plugin_runner_remote*
 %exclude %{python_sitelib}/avocado_framework_plugin_runner_vm*
 %exclude %{python_sitelib}/avocado_framework_plugin_runner_docker*
 %exclude %{python_sitelib}/avocado_framework_plugin_resultsdb*
+%exclude %{python_sitelib}/avocado_framework_plugin_varianter_yaml_to_mux*
 %{_libexecdir}/avocado/avocado-bash-utils
 %{_libexecdir}/avocado/avocado_debug
 %{_libexecdir}/avocado/avocado_error
@@ -306,6 +315,18 @@ server.
 %{python_sitelib}/avocado_resultsdb*
 %{python_sitelib}/avocado_framework_plugin_resultsdb*
 
+%package plugins-varianter-yaml-to-mux
+Summary: Avocado plugin to generate variants out of yaml files
+Requires: %{name} == %{version}
+Requires: python-yaml
+
+%description plugins-varianter-yaml-to-mux
+Can be used to produce multiple test variants with test parameters
+defined in a yaml file(s).
+
+%files plugins-varianter-yaml-to-mux
+%{python_sitelib}/avocado_varianter_yaml_to_mux*
+%{python_sitelib}/avocado_framework_plugin_varianter_yaml_to_mux*
 
 %package examples
 Summary: Avocado Test Framework Example Tests
@@ -321,6 +342,9 @@ examples of how to write tests on your own.
 %{_datadir}/avocado/wrappers
 
 %changelog
+* Fri May 19 2017 Lukas Doktor <ldoktor@redhat.com> - 50.0-1
+- Separate the varianter_yaml_to_mux plugin to a separate RPM
+
 * Tue May 16 2017 Cleber Rosa <cleber@redhat.com> - 50.0-0
 - New upstream release
 

requirements.txt

 # Avocado functional requirements
-# multiplexer (avocado.core.tree)
-PyYAML>=3.11
 # .tar.xz support (avocado.utils.archive)
 pyliblzma>=0.5.3
 # REST client (avocado.core.restclient)

selftests/unit/test_mux.py

@@ -4,8 +4,9 @@ import pickle
 import unittest
 import yaml
 
+
+import avocado_varianter_yaml_to_mux as yaml_to_mux
 from avocado.core import mux, tree, varianter
-from avocado.plugins import yaml_to_mux
 
 
 if __name__ == "__main__":

setup.py

@@ -136,7 +136,6 @@ if __name__ == '__main__':
                   'journal = avocado.plugins.journal:Journal',
                   'replay = avocado.plugins.replay:Replay',
                   'tap = avocado.plugins.tap:TAP',
-                  'yaml_to_mux = avocado.plugins.yaml_to_mux:YamlToMuxCLI',
                   'zip_archive = avocado.plugins.archive:ArchiveCLI',
                   ],
               'avocado.plugins.cli.cmd': [
@@ -166,9 +165,6 @@ if __name__ == '__main__':
                   'tap = avocado.plugins.tap:TAPResult',
                   'journal = avocado.plugins.journal:JournalResult',
                   ],
-              "avocado.plugins.varianter": [
-                  "yaml_to_mux = avocado.plugins.yaml_to_mux:YamlToMux",
-                  ],
               },
           zip_safe=False,
           test_suite='selftests',