Contributing¶
Contribution Overview¶
If you would like to contribute to the development of OpenStack, you must follow the steps in this page:
If you already have a good understanding of how the system works and your OpenStack accounts are set up, you can skip to the development workflow section of this documentation to learn how changes to OpenStack should be submitted for review via the Gerrit tool:
Pull requests submitted through GitHub will be ignored.
Bugs should be filed on StoryBoard, not GitHub:
Developing bindep¶
Either install bindep and run bindep test to check you have the needed
tools, or review bindep.txt by hand.
Running Tests¶
The testing system is based on a combination of tox and testr. The canonical approach to running tests is to simply run the command tox. This will create virtual environments, populate them with dependencies and run all of the tests that OpenStack CI systems run. Behind the scenes, tox is running testr run –parallel, but is set up such that you can supply any additional testr arguments that are needed to tox. For example, you can run: tox – –analyze-isolation to cause tox to tell testr to add –analyze-isolation to its argument list.
It is also possible to run the tests inside of a virtual environment you have created, or it is possible that you have all of the dependencies installed locally already. If you’d like to go this route, the requirements are listed in requirements.txt and the requirements for testing are in test-requirements.txt. Installing them via pip, for instance, is simply:
pip install -r requirements.txt -r test-requirements.txt
In you go this route, you can interact with the testr command directly. Running testr run will run the entire test suite. testr run –parallel will run it in parallel (this is the default incantation tox uses.) More information about testr can be found at: http://wiki.openstack.org/testr
Python API¶
No internal API stability guarantees are made, but for reference here is a basic outline of the source implementation:
-
class
bindep.depends.Apk¶ apk (Alpine Linux) specific implementation.
This shells out to apk
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
-
class
bindep.depends.Brew¶ brew specific platform implementation.
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
-
class
bindep.depends.Depends(depends_string, filename=None)¶ Project dependencies.
-
active_rules(profiles)¶ Return the rules active given profiles.
- Parameters
profiles – A list of profiles to consider active. This should include platform profiles - they are not automatically included.
-
check_rules(rules)¶ Evaluate rules against the local environment.
- Parameters
rules – A list of rules, as returned by active_rules.
- Returns
A list of unsatisfied rules.
-
list_all_packages(rules, output_format='newline')¶ Print a list of all packages that are required on this platform according to the passed in rules. This is useful if we want to build RPMs based on the deps listed in bindeps.txt
- Parameters
rules – A list of rules, as returned by active_rules.
output_format – The format to print the output in. Currently we support newline format which will print 1 package per line, and csv format which prints a csv list.
- Returns
List of all required packages regardless of whether they are missing.
-
-
class
bindep.depends.Dpkg¶ dpkg specific platform implementation.
This currently shells out to dpkg, it could in future use python-apt.
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
-
class
bindep.depends.Emerge¶ emerge specific implementation.
This currently shells out to equery, it could be changed to eix to be faster but that would add another dependency and eix’s cache would need to be updated before this is run.
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
-
class
bindep.depends.Pacman¶ pacman specific implementation.
This shells out to pacman
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
-
class
bindep.depends.Platform¶ Interface for querying platform specific info.
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
-
class
bindep.depends.Rpm¶ rpm specific platform implementation.
This currently shells out to rpm, it could in future use rpm-python if that ever gets uploaded to PyPI.
-
get_pkg_version(pkg_name)¶ Find the installed version of pkg_name.
- Returns
None if pkg_name is not installed, or a version otherwise.
-
Internal Unit Tests¶
The bindep utility is developed following a test-driven methodology. These are the current tests run to ensure its internal consistency for every commit:
-
class
bindep.tests.test_depends.DistroFixture(distro_name)¶
-
class
bindep.tests.test_depends.TestApk(*args, **kwargs)¶
-
class
bindep.tests.test_depends.TestDepends(*args, **kwargs)¶
-
class
bindep.tests.test_depends.TestDpkg(*args, **kwargs)¶
-
class
bindep.tests.test_depends.TestEmerge(*args, **kwargs)¶
-
class
bindep.tests.test_depends.TestEval(*args, **kwargs)¶
-
class
bindep.tests.test_depends.TestPacman(*args, **kwargs)¶
-
class
bindep.tests.test_depends.TestRpm(*args, **kwargs)¶
-
class
bindep.tests.test_main.MainFixture¶ Encapsulate running main().
- Attr logger
The logger fixture from the process invocation.
- Attr path
The path to the root of the isolated temp dir.
-
setUp()¶ Prepare the Fixture for use.
This should not be overridden. Concrete fixtures should implement _setUp. Overriding of setUp is still supported, just not recommended.
After setUp has completed, the fixture will have one or more attributes which can be used (these depend totally on the concrete subclass).
- Raises
MultipleExceptions if _setUp fails. The last exception captured within the MultipleExceptions will be a SetupError exception.
- Returns
None.
- Changed in 1.3
The recommendation to override setUp has been reversed - before 1.3, setUp() should be overridden, now it should not be.
- Changed in 1.3.1
BaseException is now caught, and only subclasses of Exception are wrapped in MultipleExceptions.