| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Some external plugins depend derive from BuildElement and are broken
by BuildElement enabling this batching by default.
Instead, enable it in all of the individual build element plugin
implementations.
This fixes issue #800
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
For each element plugin derived from BuildElement, add reference to the
built-in functionality documentation of BuildElement.
* buildelement.py: Add anchor for built-in functionality.
* plugins/elements/*.py: Add refence to BuildElement's built-in
functionality for each build element.
Related to #713.
|
| |
|
|
| |
Fixes #424
|
| |
|
|
|
|
|
|
|
|
|
|
| |
o Now the page titles are declared in plugins, allowing for
a more descriptive ToC
o Makefile and plugin.rsttemplate updated to not produce the title,
to no longer use `:orphan:` for plugin pages, and to ignore any
private modules in the plugin directories.
o Interestingly, now the docs will fail to build if you add
a new plugin and forget to add it to the documentation.
|
|
|
Packaging is a big topic in the Python community these days. Things are
evolving, but a consensus seems to have formed around the path forward.
With PEP 518, Pip is becoming the primary tool to install Python
modules. In turn, Pip will use the right underlying tool for the job.
(distutils, setuptools, flint, ...)
Given all this, it makes sense to have a pip element in BuildStream.
This element installs a single Python module, telling Pip not to go and
download its dependencies, to make builds reproducible and not rely
on the network during builds.
By default it will use the `pip` command which generally points to Pip
for Python 2. Users can override the "pip" variable, for example to use
the `pip3` command, which generally points to Pip for Python 3.
|
