This is an attempt to catch most (if not all) usages of open
that do not follow the context manager pattern.

Sometimes, for better readability, our own `genio` library is
used.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Instead of the iterator next method.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There's a problem with assuming that all existing plugins will
be setup at API docs creation time, initially on RPM builds but
could also happen on systems that lack dependencies for some of
the plugins.

Let's only build docs for those that have been properly setup
and are available to be imported.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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>

With more and more optional plugins it could be useful to build their
API documentation in order to be able to refer to it from the main
documentation.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The api-utils description is rather simplistic. Let's add a line related
to the purpose of `utils` to set the goals for writing custom libraries.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Older python-sphinx cannot handle newer inventory files (objects.inv).
While this is not fail proof, as there can be newer python-sphinx on
older Python, but it seems to be good enough as it works on all system
setups I tested.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Some older versions of sphinx do not ship with `sphinx-apidoc`.
Instead of breaking the document generation and selftests, let's just
skip the generation of API docs.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Added version file and updated the respective files

Sphinx actually use the contents of the `release` variable as the
user visible version number, so release here is very different from,
say, a RPM release number.

Let's set the release number to the very same version number.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

It is expected to be string, not integer.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

This release introduces a new versioning scheme, so the "big bump"
from 0.34.0 to 35.0 is not such a big bump.

Some additional changes with regards to versioning were added, such as
the way the remote runner checks for Avocado on the remote host.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

Avocado currently has 3 very distinct namespaces boundaries: test
API, utils, and core. Let's create 3 separate sections so that
users know which one(s) they could use for a given task.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

While still making the VERSION symbol available in the top level
Avocado module. Even though this is very simple information that
could live under the avocado module itself, it would break the
consistency of having avocado.core importing from avocado (toplevel).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

For completeness purporses this adds the current year to the copyright
string.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

As it was done in the man pages a while ago, it's probably better to
just refer to the Avocado Team as the author of the documentation as a
whole.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Commit 120345aa attempted to download and build avocado-virt API
documentation together with the avocado API. While this was reliable
offline, it succeeded only on the very first version builds at
readthedocs.org.

So, let's revert back that hackish form of combining the docs. Further
commits will add API documentation generation to avocado-virt itself,
and link avocado and avocado-virt by means of the intersphinx mapping
feature and readthedocs.org sub-project support.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This patch will checkout the avocado-virt repo during the documentation
build, so that all of avocado's API (including -virt) is presented at a
single and comprehensive location.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The reasons for the proposed move include:

1) Even though find_command() looks for executables, it doesn't really
   try to execute them as a living process.

2) The implementation looks for it in a $PATH like list, so, out of a
   possibly better choice, avocado.utils.path was chosen.

3) Other modules can use that functionality, but not the execution of
   process.

4) Avoid circular dependencies: this is actually the first motivation
   of the proposed change, and a true story with the GDB plugin/test.
   Since avocado.utils.process depends on avocado.gdb, this module
   can not use find_command() to look for gdb/gdbserver binaries.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Remove the license text from files inside docs, examples and selftest,
to keep the license text only in relevant parts of the project.

References:

* https://fedoraproject.org/wiki/Packaging:LicensingGuidelines
* https://www.gnu.org/licenses/gpl-howto.htmlSigned-off-by: NRudá Moura <rmoura@redhat.com>

Use `Avocado` to project name.
Signed-off-by: NRuda Moura <rmoura@redhat.com>

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

IMHO, the generated sphinx config file is too noisy and thus hard to
manage. Let's clean it up.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Add some exceptions to the Eclipse Pydev linting system,
so those false negatives don't show.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Instead of manually updating the API rst files upon
new module additions, auto generate the .rst files
through a trick on conf.py.

With this we have reduced maintenance and always
up to date API docs.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

We had to set the autoclass_content param in conf.py.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

It is useful to build avocado docs locally and have them
look mostly identical to the reference documentation,
hosted in read the docs. The theme can be installed using
pip with:

pip install sphinx_rtd_theme

And if not present, the build should gracefully
degrade to the sphinx default.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>