💡说明
https://facebook.github.io/prophet/docs/contributing.html
先知的发布周期是非固定的，但我们会根据用户的反馈进行bug修复并增加功能。如果你遇到一个bug，请通过提交问题让我们知道。Github issues也是询问有关使用Prophet问题的正确地方。
我们感谢所有的贡献。如果你打算回馈bug修复，请不要再讨论。
如果你打算为核心提供新的功能或扩展，请先打开一个issue，与我们讨论该功能。发送pull请求也是可以的，但如果事先在issue中确定了任何设计决定，那么它可能会更快地被合并。
R和Python版本保持了相同的特性，但每个方法都可以在单独的提交中实现新特性。
下面的章节将介绍如何提交拉取请求，以便向代码库添加增强功能、修改文档或修复错误。
You will need your own fork to work on the code. Go to the fbprophet project page https://github.com/facebook/prophet and hit the Fork button. You will want to clone your fork to your machine::
$ git clone <https://github.com/your-user-name/prophet.git>
$ cd prophet
$ git remote add upstream <https://github.com/facebook/prophet.git>
This creates the directory prophet and connects your repository to the upstream (main project) fbprophet repository.
Before starting any development, you’ll need to create an isolated prophet development environment. This should contain the required dependencies.
conda update conda)cd to the prophet source directory that you have cloned$ cd python
# with Anaconda
$ conda create -n prophet
$ conda activate prophet
$ pip install -r requirements.txt
# with venv
$ python3 -m venv prophet
$ source prophet/bin/activate
$ pip install -r requirements.txt
Dependencies can be managed through Packrat (https://rstudio.github.io/packrat/) or renv (https://rstudio.github.io/renv/articles/renv.html).
For renv, you must first initialise a new project local environment.
> setwd("path/to/prophet/R") # set R subdirectory as working directory
> install.packages('renv')
> renv::init()
This should also install the dependencies listed in the DESCRIPTION automatically. Any new R packages can be installed as they are needed in the project.
You can save the state of the project:
> renv::snapshot()
or load the environment:
> renv::restore()
The next step is to build and install the development version of prophet in the environment you have just created.
$ python setup.py develop
You should be able to import fbprophet from your locally built version:
$ python # start an interpreter
>>> import fbprophet
>>> fbprophet.__version__
'0.6.1.dev0' # whatever the current github version is
'0.10.0+dev46.g015daca'
This will create the new environment, and not touch any of your existing environments, nor any existing Python installation.
# to view your environments:
$ conda info -e
# to return to your root environment::
$ conda deactivate
See the full conda docs here http://conda.pydata.org/docs.
From the terminal, cd to R subdirectory and run:
$ R CMD INSTALL .
This will build and install the local version of the prophet package. Then from the R console you can load the package: library(prophet).
You want your master branch to reflect only production-ready code, so create a feature branch for making your changes. For example:
$ git checkout -b new-feature
This changes your working directory to the new-feature branch. Keep any changes in this branch specific to one bug or feature so it is clear what the branch brings to fbprophet. You can have many “new-features” and switch in between them using the git checkout command.
To update this branch, you need to retrieve the changes from the master branch:
$ git fetch upstream
$ git rebase upstream/master
This will replay your commits on top of the latest fbprophet git master. If this leads to merge conflicts, you must resolve these before submitting your pull request. If you have uncommitted changes, you will need to git stash them prior to updating. This will effectively store your changes and they can be reapplied after updating.
Adding tests is one of the most common requests after code is pushed to prophet. Therefore, it is worth getting in the habit of writing tests ahead of time so this is never an issue. Once your pull request is submitted, the Travis CI (continuous integration) service automatically triggers Python and R builds for Prophet and runs the tests. A pull-request will be considered for merging when you have an all ‘green’ build. If any tests are failing, then you will get a red ‘X’, where you can click through to see the individual failed tests.
All contributors are strongly recommended to embrace Test Driven Development (TDD). First one must write an (initially failing) automated test case that defines a desired improvement or new function, then produce the minimum amount of code to pass that test. So, before actually writing any code, you should write your tests.
Prophet uses the unittest package for running tests in Python and testthat package for testing in R. All tests should go into the tests subdirectory in either the Python or R folders.
The entire test suite can be run by typing:
$ python setup.py tests
The entire test suite can be run from the R console by installing devtools:
> install.packages('devtools')
> devtools::test()
Alternatively the test suite can be also run from the terminal after cd to the tests directory
$ Rscript testthat.R
or for just running a single test script like test_diagnostics.R from the R console:
> library(testthat)
> source('test_diagnostics.R')
Most of the doc pages are generated from Jupyter notebooks in the notebooks directory at the base of the source tree. Please make changes there and then rebuild the docs:
$ cd docs
$ make notebooks
Make sure you have installed rpy2 so that the R code can be run as well.
In R, the documentation for the source code must also generated if new parameters are added or a new function is created. This is documented with roxygen.
Run the command below before submitting a PR with any changes to the R code to update the function documentation:
> devtools::document()
Keep style fixes to a separate commit to make your pull request more readable. Once you’ve made changes, you can see them by typing:
$ git status
If you have created a new file, it is not being tracked by git. Add it by typing:
$ git add path/to/file-to-be-added.py
Doing ‘git status’ again should give something like:
# On branch new-feature
#
# modified: /relative/path/to/file-you-added.py
#
Now you can commit your changes in your local repository:
$ git commit -m
When you want your changes to appear publicly on your GitHub page, push your forked feature branch’s commits:
$ git push origin new-feature
Here origin is the default name given to your remote repository on GitHub. You can see the remote repositories:
$ git remote -v
If you added the upstream repository as described above you will see something like:
origin [email protected]:yourname/prophet.git (fetch)
origin [email protected]:yourname/prophet.git (push)
upstream <https://github.com/facebook/prophet.git> (fetch)
upstream <https://github.com/facebook/prophet.git> (push)
Now your code is on GitHub, but it is not yet a part of the fbprophet project. For that to happen, a pull request needs to be submitted on GitHub.
When you’re ready to ask for a code review, file a pull request. Before you do, once again make sure that you have followed all the guidelines outlined in this document regarding code style, tests, performance tests, and documentation. You should also double check your branch changes against the branch it was based on:
If everything looks good, you are ready to make a pull request. A pull request is how code from a local repository becomes available to the GitHub community and can be reviewed and eventually merged into the master version. This pull request and its associated changes will eventually be committed to the master branch and available in the next release. To submit a pull request:
This request then goes to the repository maintainers, and they will review the code. If you need to make more changes, you can make them in your branch, add them to a new commit, push them to GitHub, and the pull request will be automatically updated. Pushing them to GitHub again is done by:
$ git push origin new-feature
This will automatically update your pull request with the latest code and restart the Continuous Integration tests.
Once your feature branch is merged into upstream master, you can delete your remote branch via the Delete branch option in the PR and the local copy by running:
$ git branch -d new-feature
devtools:check() for carrying out a number of automated checks all at once, for code problems, documentation, testing, package structure, vignettes etc. This will take a few minutes to run.