- Parse our requirements.txt to keep install_requires up to date.
- Create extras builds for talib and dev.
- Use pip install -e .[dev] on Travis to install Zipline before testing.
This patch lays the groundwork for a compute engine designed to
facilitate construction of factor-based universe screening and portfolio
allocation. It contains:
A new module, `zipline.modelling`, containing entities that can be used
to express computations as dependency graphs. Each node in such a graph
is an instance of the base `Term` class, defined in
`zipline.modelling.term`. Dependency graphs are executed by instances
of `FFCEngine`, defined in `zipline.modelling.engine`.
A new module, `zipline.data.ffc`, containing loaders and dataset
definitions for inputs to the modelling API.
New `TradingAlgorithm` api methods: `add_factor`, and `add_filter`.
These methods can only be called from `initialize`, and are used to
inform the algorithm that each day it should compute the given terms.
Computed factor results are made available through a new attribute of
the `data` object in `before_trading_start` and `handle_data`. Computed
filter results control which assets are available in the factor matrix
on each day.
Move the responsibility of wrapping the main simulation loop in the
ZiplineAPI context from the algorithm modules generator setup to the
main trade simulation loop, so that different methods of invoking loop
do not need to duplicate how the context is set.
To make it easier for internal implementation of handle_data to
transition off of calling the ZiplineAPI every bar, to only invoking the
context once per simulation.
In d01e718373, we made a change for
compatibility with a change introduced in pip 7.0.0. Then the pip
maintainers went and reverted the change in pip 7.0.2, thereby
breaking our requirements file for the second time in ten days. This
change reverts the prior change so that we are once again compatible
with the current version of pip.
Also, to make it easier for people to avoid pip compatibility issues,
we're now specifying pip>=7.0.3 in etc/requirements.txt.
Because we use ordered_pip.sh to install requirements files, we want
dependencies in requirements_dev.txt to be listed _before_ the things
that depend on them, rather than after. Otherwise, with
ordered_pip.sh, stuff will get installed implicitly, and perhaps the
wrong version.
llllllllll