de9b2fc6a1
Introduced changes: - pre-commit config and rules. - Add pre-commit to pep8 gate, Flake8 is covered in the pre-commit hooks. - Applying fixes for pre-commit compliance in all code. Also commit hash will be used instead of version tags in pre-commit to prevend arbitrary code from running in developer's machines. pre-commit will be used to: - trailing whitespace; - Replaces or checks mixed line ending (mixed-line-ending); - Forbid files which have a UTF-8 byte-order marker (check-byte-order-marker); - Checks that non-binary executables have a proper shebang (check-executables-have-shebangs); - Check for files that contain merge conflict strings (check-merge-conflict); - Check for debugger imports and py37+ breakpoint() calls in python source (debug-statements); - Attempts to load all yaml files to verify syntax (check-yaml); - Run flake8 checks (flake8) (local) For further details about tests please refer to: https://github.com/pre-commit/pre-commit-hooks Change-Id: I045fa1cd7932d960e1cf49b2c335c7acdeba0b46 Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
39 lines
1.9 KiB
ReStructuredText
39 lines
1.9 KiB
ReStructuredText
===============================
|
|
Guidelines for Naming Plugins
|
|
===============================
|
|
|
|
Stevedore uses setuptools entry points to define and load plugins. An
|
|
entry point is standard way to refer to a named object defined inside
|
|
a Python module or package. The name can be a reference to any class,
|
|
function, or instance, as long as it is created when the containing
|
|
module is imported (i.e., it needs to be a module-level global).
|
|
|
|
Names and Namespaces
|
|
====================
|
|
|
|
Entry points are registered using a *name* in a *namespace*.
|
|
|
|
Entry point names are usually considered user-visible. For example,
|
|
they frequently appear in configuration files where a driver is being
|
|
enabled. Because they are public, names are typically as short as
|
|
possible while remaining descriptive. For example, database driver
|
|
plugin names might be "mysql", "postgresql", "sqlite", etc.
|
|
|
|
Namespaces, on the other hand, are an implementation detail, and while
|
|
they are known to developers they are not usually exposed to users.
|
|
The namespace naming syntax looks a lot like Python's package syntax
|
|
(``a.b.c``) but *namespaces do not correspond to Python
|
|
packages*. Using a Python package name for an entry point namespace is
|
|
an easy way to ensure a unique name, but it's not required at all.
|
|
The main feature of entry points is that they can be discovered
|
|
*across* packages. That means that a plugin can be developed and
|
|
installed completely separately from the application that uses it, as
|
|
long as they agree on the namespace and API.
|
|
|
|
Each namespace is owned by the code that consumes the plugins and is
|
|
used to search for entry points. The entry point names are typically
|
|
owned by the plugin, but they can also be defined by the consuming
|
|
code for named hooks (see :class:`~stevedore.hook.HookManager`). The
|
|
names of entry points must be unique within a given distribution, but
|
|
are not necessarily unique in a namespace.
|