And favor a system wide path for `avocado exec-path`, in the same way
we prefer the `/etc/avocado` files.  If not running from packages, the
Python version specific location will be used.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

With content that is common to both Python 2 and Python 3 versions of
the Avocado packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

Commit 24f3b936 removed compatibility with package name "avocado", but
missed that for plugins.  Let's remove those too.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Both branches of the conditional includes distros we build packages
for.  So, it's safe to use that "naked" build requirement.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We currently build on EL7, Fedora 26 and Fedora 27.

On EL7, some of the Python packages are prefixed with "python2", and
some others are not.  We have been previously using the name of
"Provides" instead of the real package names.

Now, Python package names on Fedora 26 and Fedora 27 are the same for
those we depend on.

This adds a conditional block for EL7, and another one for Fedora 26
and 27.  Some Python packages have been kept on both blocks, in
preparation for the Python 3 packaging that will happen only for the
Fedora packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The package is named PyYAML on EL7, so let's use the correct name, and
not the name of "Provides" tag.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We don't build on Fedora 24 anymore, so let's remove this hack.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

It's about time we stop providing support for "avocado".  The other
package the project ships, "avocado-plugins-vt" (also badly named)
uses python-avocado as a requirement name.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

Unless a lower version is set as a requirement, the RPM building
process will attempt to download from PyPI, which is not allowed.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

With the recent changes the "libexec" dir is only available when
installed via RPM. In order to have "libexec" files available
as standard package we have to include it in  the package_files
dir (avocado/). The benefit is that we can actually use package
resources to get the location in "avocado exec-path" command.

For packaging purposes let's simply symlink $libexec/avocado to the
packaged $avocado/libexec location so there is the usual location, but
keep using the python-location by default.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

To remove some of the bloat (even if little) of the base
python-avocado package, let's move content that is not useful to
Python developers out of the way.

This should also make the experience of content more similar across
users of the Python module (say, from a `pip install`) and users of
the python-avocado package.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There's little to no point in providing these files, since the
generated man pages are already packaged.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Leaving them only in the source distribution generation (if one runs
python setup.py sdist) and in the "example" RPM package.

Because the copying of those files won't be performed by the Python
module installation code, it must be done in the SPEC file.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

These files weren't being installed by the setup.py code, and thus
ended up missing from RPM packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

In a pure Python world[1] the "avocado" module requires the existence
of these configuration files.  Let's make those configuration files
"data files" of that module.

Since the configuration location can now be a different, the settings
module needs adjustments to also attempt to load them from package
resources (which is tied to the data files).

Finally, when using RPM packages, we need to put the configuration
back into the system location (/etc).

[1] - that is, ignoring operating system or distribution specific
      conventions and packaging technologies
Signed-off-by: NCleber Rosa <crosa@redhat.com>

So there are no clases in history of RPM releases.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

This builds a new sub package for this new optional plugin.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

PICT is a free software (MIT licensed) tool that implements
combinatorial testing.  Information about it can be found here:

   https://github.com/Microsoft/pict/

This is a very simple, but functional varianter implementation.  It
performs the basic tasks of creating variants and making parameters
accessible to tests.  To test this version, it's recommended to
download PICT, build it (it only takes a C compiler such as GCC or
clang and make) and put it in a location included in your PATH (or use
`--pict-binary`).

To list the variants generated with the default order (2, that is,
do a pairwise idenpendent combinatorial testing):

 $ avocado variants --pict-parameter-file=examples/params.pict
 Pict Variants (11):
 Variant amd-scsi-rtl8139-windows-rhel6-acff:    /run
 ...
 Variant amd-ide-e1000-linux-rhel6-eb43:    /run

To list the variants generated with a 3-way combination:

 $ avocado variants --pict-parameter-file=examples/params.pict \
   --pict-order-of-combinations=3

 Pict Variants (28):
 Variant intel-ide-virtio-windows-rhel7-aea5:    /run
 ...
 Variant intel-scsi-e1000-linux-rhel7-9f61:    /run

It's also possible to run tests with variants generated by the same
command line switches.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

Let's also package and build the recently introduced golang plugin.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There's a problem with the current SPEC file in that it doesn't
exclude some of the files part of the "plugins-loader-yaml" package.

This would cause problems if that plugin package attempts to be
installed, causing conflicts because they're packaged on two packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This commit revomes flexmock from the various requirements file, from
the RPM SPEC file.  Starting here, it's officially no longer an
Avocado dependency.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

six is already a stevedore requirement, but since we'll now be
using it directly, it's a good idea to list it explicitly as
a dependency.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

A number of example files are not currently being packaged.  Let's
install and package them.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The current SPEC file changelog is getting really long.  I think
we can do better with a shorter version.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

The newly introduced YAML Loader plugin is currently hosted on the
same plugin (directory and module) as the varianter one.  While they
share a lot of code, they have different purposes.

Let's move the YAML loader into its own plugin, so that its
installation is also optional and the separation is clearer.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This change is already present on the downstream (Fedora/EPEL)
packages, and for some reason, was missing here.  It causes
the installation to be attempted by pip, which should never
be done during RPM builds.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

shortcommit is supposed to contain the 8 first characters instead of 7.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

There's now python-aexpect packages on EL7, so we should
be using it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>