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

While going through the dependency list (requirements*.txt files) and
performing our self tests out of virtual environments, I noticed that
some tests are run outside the virtual environments.

The reason is that, even though the virtual environment is activated
for the test session (and say, `which python` gives `/venv/bin/python`),
we have hard coded `/usr/bin/python` in most places.

According to the some discussions on the virtualenv project itself[1],
a quick solution is to revert to the also common `/usr/bin/env python`
way of pointing to the Python interpreter.

[1] - https://github.com/pypa/virtualenv/issues/124Signed-off-by: NCleber Rosa <crosa@redhat.com>

Fix test providers checkout

Var "lbranch" was hard coded to "master", so it was never copied from var "branch".

"make check" needs pydot to run.

We used to support subtests filter to load only some of the avocado
tests, but the functionality is broken. This patch brings this
functionality back. It uses "re.search" so people can use partial
matches. Additionally it includes selftests to prevent future breakages.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This patch adds unittest for loading simple tests with arguments.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

requirements-travis.txt: Require inspektor 0.2.0

Inspektor 0.2.0 has some improvements in the queue,
mainly now by default we are going to start being
picky on unused imports. Which is something I wanted
to do for a long time.
Signed-off-by: NLucas Meneghel Rodrigues <lookkas@gmail.com>

Signed-off-by: NLucas Meneghel Rodrigues <lookkas@gmail.com>

avocado: Fixing unused imports

This was caught by modified inspektor check. I'm still
working on inspektor, meanwhile let's send this fix.
Signed-off-by: NLucas Meneghel Rodrigues <lookkas@gmail.com>

When the test process exits before the deadline, it raises exception
while trying to destroy it. Let's just ignore the OSError and proceed.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>