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

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

Yes, too many plugin mentions, in this commit title, but that's what
it really is, so please bear with it.

Now that the plugin types have a finer granularity, let's show each
plugin type (based on the namespace) as a separate section.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@scylladb.com>
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

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

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

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

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

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

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

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 Avocado command line application has "subcommands". So far,
to execute these commands, a special method, named "dispatch"
was set on the command line parser result object (aka Namespace)
pointing to the `run` method of the same class.

In truthfullness, the command line parser doesn't have too much
to do with these methods. Also, the `set_defaults` method of the
command line argument parser is not exactly intended for that use.
So, let's ask the subcommands subparser to formally save the chosen
subcommand, at well, `subcommand`, and nothing more.

Since the application knows about the command plugins (the ones that
inherit from CLICmdBase), and their interface now *require* a method
called `run`, let's use the extension entry-point name to locate the
underlying object and its `run` method.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The `CLICmdDispatcher` is responsible for loading and configuring all
plugins based on `CLICmdBase`. After registering the entry point to
the documented namespace (avocado.plugins.cli.cmd) the new command
should be visible just by running `$ avocado` or `$ avocado --help`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

The CLICmd, is a base class for plugins that want to add commands
to the Avocado command line application. These commands should be
given by a user right after the command line application itself, as
it's common practice in most CLI tools.

This class has minimal functionality (some in the configure method),
and its main goal is to define the interface that plugin developers
should follow.

The only mandatory steps for "CLICmd" plugins are a name, and the
`run` method. `configure` will, by default register the command
with Avocado command line parser.

By doing just that, the new command is visible on the Avocado command
line application. So, if a plugin named "foo" would introduce a
command with the same name (ideally, for consistency) it would be
called with:

 $ avocado foo

And it's help message would be visible with:

 $ avocado foo --help

Other command line options to a given introduced command can be added
by writing a custom `configure` method.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

At this point, no plugin support exists in Avocado. This is in
preparation for the new plugin code to be cleanly introduced.

The plugins that play a role in the plugin architecture have
been removed, since they wouldn't be functional under the new
plugin management code. The ones that are add extra functionality
to Avocado have been kept, and will be ported to the new
architecture.

Also, most of the functional tests have been temporarily disabled.
The reason is that most of them run avocado, which depends on the
run command, which in turn, depends on the plugin archicture code.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The new plugin architecture depends on setuptools entry points being
properly registered. These entry points are defined in a `setup.py`
file, as the `entrypoints` parameter, but they are only effective when
they become an `entry_points.txt` file inside a
`<your_project>.egg_info` directory.

This can happen in two ways:

1) installing the package, that is, running `$ python setup.py
install`

2) enabling the development mode, that is, running `$ python setup.py
develop`.

The approach chosen here is the latter, because it's faster, doesn't
require a full install and points to the checked out source code tree.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This shows a more succint version of the help message (the so called
"usage" information). It's a certainly a matter of taste and change
of behavior, so this is marked as an RFC.

It also avoids a hackish injection of the print_help method as the
default dispatch method.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Makefile: Add requirements-python26 [v2]

Again, let's short target names. It helps with typing and makes the
documentation fit better most screens.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The install requirements targets are really best effort. PIP can fail
in so many ways. So, let's not attempt to detect if the target ran
successfully or not. This is important because it may prevent other
chained command lines and targets to attempted an execution.

Also attempt to install Python 2.6 requirements early, since they are
simpler than the other requirements and pretty much basic back ported
libraries.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Let's separate those to aid in a quick visual identification. Also,
users are probably different among those three target groups.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

IMHO short names for Makefile targets are desirable, so let's shorten
the names of the Debian related targets. Also, they better match the
RPM target names like that.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Simple attempt to give the help message output a better look.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

To simplify usage with python2.6 add requirements-python26.txt which
adds python2.6 requirements (on top of requirements.txt). It includes
booth avocado and selftest dependencies and is automatically invoked
when running on system with python 2.6.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Without the --upgrade the installation fails when the package of
incompatible version is already installed.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This fixes the recently introduced commit 5f7bafd0, running the skip
function instead of passing the function itself to `unittest.skipIf`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

selftests/functional/test_output.py: skip test on absence of PIL library

The `test_gendata` test of `OutputTest` runs the example test
`gendata.py`, but the `gendata.py` itself has a conditional in one of
the tests that make use of the PIL (aka Pillow package) library and
does nothing if it's missing.

PIL (Pillow) is highly dependent on C compilers and libraries to be
able to build itself. This makes systems it harder to run the full
Avocado self tests on more diverse (usually minimalist) systems.

So, let's make that functional test optional, if the libraries are not
present.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Human output: functional test fixes [v2]

There are a couple of functional unittests that assume that a given
output was produced by the regular UI, that is, the Human output
format.

That is fine, since they're functional tests. But, some situations
lead to test errors, instead of pointing failures. Let's turn those
into explicit checks and fail properly instead of producing errors.

Note: These errors were visible when the human output was disabled, in
the plugin overhaul work, but the fixes still make sense independently
of that work.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

scripts.avocado: Use /var/tmp if TMP not set in env

Some distributions mount /tmp as tmpfs, which does not implement all
usual filesystem functions, like O_DIRECT flag. This causes problems for
some tests. Let's check if the user already set TMP in environment and
if not, try to use /var/tmp by default.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

virtualenv: allow tests to run properly on them