Based on previous experiences (GDB terminal redirection attempts),
it's common for applications that need to allocate a pseudo to have
the name of the allocated file. This is, unfortunately, something that
the Python standard library doesn't give for free.

This simple utility module wraps and extends the Python standard
library `pty` module, providing a `openpty` function that, besides
allocating the pseudo terminal, also returns its name.
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 63077e79 introduced the `make requirements` target. Let's use
that on the documentation, since it can cover more scenarios such
as Python 2.6 users.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There has been a lot of file location updates with the plugin architecture
changes.

Also python-stevedore is also required at build time, because on some
arches the selftests are run during the package build.

Let's reflect those in the RPM packages.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Commit f415c4d8 introduced this useful feature. Let's document
how it can be used.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

Plugins Overhaul [v1]

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

Optionally, users may have plugins that fail to load, but that should
still be kept installed. It can be annoying to have the same message
over and over, so let's allow users to configure which plugins should
have their load errors silenced.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Let's log when plugins fail to loaded for any reason. The error
message is given right after the plugins are attempted to be loaded,
so they may show before any other user visible output.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

Including the old base plugin class definition.
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>

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>