首页 > 其他 > 详细

zipline-- 开发指南

时间:2018-08-16 16:18:08      阅读:37      评论:0      收藏:0      [点我收藏+]

标签:check   最好的   contain   oot   guide   pri   UNC   source   提交   

Development Guidelines
This page is intended for developers of Zipline, people who want to contribute to the Zipline codebase or documentation, or people who want to install from source and make local changes to their copy of Zipline.
All contributions, bug reports, bug fixes, documentation improvements, enhancements and ideas are welcome. We track issues on GitHub and also have a mailing list where you can ask questions.


Creating a Development Environment
First, you’ll need to clone Zipline by running:

$ git clone git@github.com:your-github-username/zipline.git

Then check out to a new branch where you can make your changes:

$ git checkout -b some-short-descriptive-name

If you don’t already have them, you’ll need some C library dependencies. You can follow the install guide to get the appropriate dependencies.
The following section assumes you already have virtualenvwrapper and pip installed on your system. Suggested installation of Python library dependencies used for development:

$ mkvirtualenv zipline
$ ./etc/ordered_pip.sh ./etc/requirements.txt
$ pip install -r ./etc/requirements_dev.txt
$ pip install -r ./etc/requirements_blaze.txt

Finally, you can build the C extensions by running:

$ python setup.py build_ext --inplace

To finish, make sure tests pass.
If you get an error running nosetests after setting up a fresh virtualenv, please try running

# where zipline is the name of your virtualenv
$ deactivate zipline
$ workon zipline

Development with Docker
If you want to work with zipline using a Docker container, you’ll need to build the Dockerfile in the Zipline root directory, and then build Dockerfile-dev. Instructions for building both containers can be found in Dockerfile and Dockerfile-dev, respectively.
如果您想使用Docker容器与Zipline一起工作,则需要在zipline的root目录中构建Dockerfile文件,然后构建Dockerfile-dev。在Dockerfile and Dockerfile-dev中分别找到用于构建这两个容器的指令。

Style Guide & Running Tests
We use flake8 for checking style requirements and nosetests to run Zipline tests. Our continuous integration tools will run these commands.
Before submitting patches or pull requests, please ensure that your changes pass when running:

$ flake8 zipline tests


In order to run tests locally, you’ll need TA-lib, which you can install on Linux by running:
为了在本地运行测试,您需要TA LIB,您可以通过在Linux上安装运行:

$ wget http://prdownloads.sourceforge.net/ta-lib/ta-lib-0.4.0-src.tar.gz
$ tar -xvzf ta-lib-0.4.0-src.tar.gz
$ cd ta-lib/
$ ./configure --prefix=/usr
$ make
$ sudo make install

And for TA-lib on OS X you can just run:
对于OSX上的TA LIB,您可以运行:

$ brew install ta-lib

Then run pip install TA-lib:

然后运行PIP安装TA LIB:

$ pip install -r ./etc/requirements_talib.txt

You should now be free to run tests:


$ nosetests


Continuous Integration
We use CI for Linux-64 bit builds and AppVeyor for Windows-64 bit builds.
我们使用Travis CI为Linux-64位构建和 AppVeyor为Windows 64位构建。

To learn about how we build Zipline conda packages, you can read this section in our release process notes.
要了解我们如何构建ZiPin CONDA软件包,您可以在我们的发布过程日记中阅读这一部分。

Contributing to the Docs
If you’d like to contribute to the documentation on zipline.io, you can navigate to docs/source/ where each reStructuredText (.rst) file is a separate section there. To add a section, create a new file called some-descriptive-name.rst and add some-descriptive-name to appendix.rst. To edit a section, simply open up one of the existing files, make your changes, and save them.
如果您想为ZiPix.IO的文档作出贡献,您可以导航到docs/source/的每个 reStructuredText (.rst)文件,其中的每一个都是单独的一个部分。要添加一个部分,创建一个名为some-descriptive-name.rst的新文件,并将some-descriptive-name添加到appendix.rst。要编辑一个部分,只需打开现有文件中的一个,进行更改,然后保存它们。
We use Sphinx to generate documentation for Zipline, which you will need to install by running:

$ pip install -r ./etc/requirements_docs.txt

To build and view the docs locally, run:


# assuming you‘re in the Zipline root directory
$ cd docs
$ make html
$ {BROWSER} build/html/index.html

Commit messages
Standard prefixes to start a commit message:

BLD: change related to building Zipline
BUG: bug fix
DEP: deprecate something, or remove a deprecated object
DEV: development tool or utility
DOC: documentation
ENH: enhancement
MAINT: maintenance commit (refactoring, typos, etc)
REV: revert an earlier commit
STY: style fix (whitespace, PEP8, flake8, etc)
TST: addition or modification of tests
REL: related to releasing Zipline
PERF: performance enhancements

Some commit style guidelines:
Commit lines should be no longer than 72 characters. The first line of the commit should include one of the above prefixes. There should be an empty line between the commit subject and the body of the commit. In general, the message should be in the imperative tense. Best practice is to include not only what the change is, but why the change was made.


MAINT: Remove unused calculations of max_leverage, et al.

In the performance period the max_leverage, max_capital_used,
cumulative_capital_used were calculated but not used.

At least one of those calculations, max_leverage, was causing a
divide by zero error.

Instead of papering over that error, the entire calculation was
a bit suspect so removing, with possibility of adding it back in
later with handling the case (or raising appropriate errors) when
the algorithm has little cash on hand.

Formatting Docstrings
When adding or editing docstrings for classes, functions, etc, we use numpy as the canonical reference.

Updating the Whatsnew
We have a set of whatsnew files that are used for documenting changes that have occurred between different versions of Zipline. Once you’ve made a change to Zipline, in your Pull Request, please update the most recent whatsnew file with a comment about what you changed. You can find examples in previous whatsnew files.

zipline-- 开发指南

标签:check   最好的   contain   oot   guide   pri   UNC   source   提交   


评论 一句话评论(0
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4

鲁公网安备 37021202000002号