| ... |
... |
@@ -553,7 +553,7 @@ One problem which arises from this is that we end up having symbols |
|
553
|
553
|
which are *public* according to the :ref:`rules discussed in the previous section
|
|
554
|
554
|
<contributing_public_and_private>`, but must be hidden away from the
|
|
555
|
555
|
*"Public API Surface"*. For example, BuildStream internal classes need
|
|
556
|
|
-to invoke methods on the ``Element`` and ``Source`` classes, wheras these
|
|
|
556
|
+to invoke methods on the ``Element`` and ``Source`` classes, whereas these
|
|
557
|
557
|
methods need to be hidden from the *"Public API Surface"*.
|
|
558
|
558
|
|
|
559
|
559
|
This is where BuildStream deviates from the PEP-8 standard for public
|
| ... |
... |
@@ -631,7 +631,7 @@ An element plugin will derive from Element by importing:: |
|
631
|
631
|
|
|
632
|
632
|
from buildstream import Element
|
|
633
|
633
|
|
|
634
|
|
-When importing utilities specifically, dont import function names
|
|
|
634
|
+When importing utilities specifically, don't import function names
|
|
635
|
635
|
from there, instead import the module itself::
|
|
636
|
636
|
|
|
637
|
637
|
from . import utils
|
| ... |
... |
@@ -737,7 +737,7 @@ Abstract methods |
|
737
|
737
|
~~~~~~~~~~~~~~~~
|
|
738
|
738
|
In BuildStream, an *"Abstract Method"* is a bit of a misnomer and does
|
|
739
|
739
|
not match up to how Python defines abstract methods, we need to seek out
|
|
740
|
|
-a new nomanclature to refer to these methods.
|
|
|
740
|
+a new nomenclature to refer to these methods.
|
|
741
|
741
|
|
|
742
|
742
|
In Python, an *"Abstract Method"* is a method which **must** be
|
|
743
|
743
|
implemented by a subclass, whereas all methods in Python can be
|
| ... |
... |
@@ -960,7 +960,7 @@ possible, and avoid any cyclic relationships in modules. |
|
960
|
960
|
For instance, the ``Source`` objects are owned by ``Element``
|
|
961
|
961
|
objects in the BuildStream data model, and as such the ``Element``
|
|
962
|
962
|
will delegate some activities to the ``Source`` objects in its
|
|
963
|
|
-possesion. The ``Source`` objects should however never call functions
|
|
|
963
|
+possession. The ``Source`` objects should however never call functions
|
|
964
|
964
|
on the ``Element`` object, nor should the ``Source`` object itself
|
|
965
|
965
|
have any understanding of what an ``Element`` is.
|
|
966
|
966
|
|
| ... |
... |
@@ -1223,7 +1223,7 @@ For further information about using the reStructuredText with sphinx, please see |
|
1223
|
1223
|
Building Docs
|
|
1224
|
1224
|
~~~~~~~~~~~~~
|
|
1225
|
1225
|
Before you can build the docs, you will end to ensure that you have installed
|
|
1226
|
|
-the required :ref:`buid dependencies <contributing_build_deps>` as mentioned
|
|
|
1226
|
+the required :ref:`build dependencies <contributing_build_deps>` as mentioned
|
|
1227
|
1227
|
in the testing section above.
|
|
1228
|
1228
|
|
|
1229
|
1229
|
To build the documentation, just run the following::
|
| ... |
... |
@@ -1365,7 +1365,7 @@ Structure of an example |
|
1365
|
1365
|
'''''''''''''''''''''''
|
|
1366
|
1366
|
The :ref:`tutorial <tutorial>` and the :ref:`examples <examples>` sections
|
|
1367
|
1367
|
of the documentation contain a series of sample projects, each chapter in
|
|
1368
|
|
-the tutoral, or standalone example uses a sample project.
|
|
|
1368
|
+the tutorial, or standalone example uses a sample project.
|
|
1369
|
1369
|
|
|
1370
|
1370
|
Here is the the structure for adding new examples and tutorial chapters.
|
|
1371
|
1371
|
|
| ... |
... |
@@ -1471,8 +1471,8 @@ Installing build dependencies |
|
1471
|
1471
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
1472
|
1472
|
Some of BuildStream's dependencies have non-python build dependencies. When
|
|
1473
|
1473
|
running tests with ``tox``, you will first need to install these dependencies.
|
|
1474
|
|
-Exact steps to install these will depend on your oprtation systemm. Commands
|
|
1475
|
|
-for installing them for some common distributions are lised below.
|
|
|
1474
|
+Exact steps to install these will depend on your operating system. Commands
|
|
|
1475
|
+for installing them for some common distributions are listed below.
|
|
1476
|
1476
|
|
|
1477
|
1477
|
For Fedora-based systems::
|
|
1478
|
1478
|
|
| ... |
... |
@@ -1540,7 +1540,7 @@ the frontend tests you can do:: |
|
1540
|
1540
|
|
|
1541
|
1541
|
tox -- tests/frontend/
|
|
1542
|
1542
|
|
|
1543
|
|
-Specific tests can be chosen by using the :: delimeter after the test module.
|
|
|
1543
|
+Specific tests can be chosen by using the :: delimiter after the test module.
|
|
1544
|
1544
|
If you wanted to run the test_build_track test within frontend/buildtrack.py you could do::
|
|
1545
|
1545
|
|
|
1546
|
1546
|
tox -- tests/frontend/buildtrack.py::test_build_track
|
| ... |
... |
@@ -1560,7 +1560,7 @@ can run ``tox`` with ``-r`` or ``--recreate`` option. |
|
1560
|
1560
|
.. note::
|
|
1561
|
1561
|
|
|
1562
|
1562
|
By default, we do not allow use of site packages in our ``tox``
|
|
1563
|
|
- confguration to enable running the tests in an isolated environment.
|
|
|
1563
|
+ configuration to enable running the tests in an isolated environment.
|
|
1564
|
1564
|
If you need to enable use of site packages for whatever reason, you can
|
|
1565
|
1565
|
do so by passing the ``--sitepackages`` option to ``tox``. Also, you will
|
|
1566
|
1566
|
not need to install any of the build dependencies mentioned above if you
|
| ... |
... |
@@ -1597,7 +1597,7 @@ under test before displaying the combined coverage. |
|
1597
|
1597
|
Adding tests
|
|
1598
|
1598
|
~~~~~~~~~~~~
|
|
1599
|
1599
|
Tests are found in the tests subdirectory, inside of which
|
|
1600
|
|
-there is a separarate directory for each *domain* of tests.
|
|
|
1600
|
+there is a separate directory for each *domain* of tests.
|
|
1601
|
1601
|
All tests are collected as::
|
|
1602
|
1602
|
|
|
1603
|
1603
|
tests/*/*.py
|
