To get up to speed, you’ll need to
See the coding style guideline here.
We do not plan to change all existing code to follow this coding style, but as we modify the code, we update it accordingly.
See the Pylearn2 main page for the pylearn-dev, theano-buildbot and pylearn2-github mailing list. They are useful to Pylearn2 contributors.
git config --global user.email you@yourdomain.example.com
git config --global user.name "Your Name Comes Here"
Clone your fork locally with
git clone git@github.com:your_github_login/pylearn2.git
and add a reference to the ‘central’ Pylearn2 repository with
git remote add central git://github.com/lisa-lab/pylearn2.git
When working on a new feature in your own fork, start from an up-to-date copy of the trunk:
git fetch central
git checkout -b my_shiny_feature central/master
Once your code is ready for others to review, push your branch to your github fork:
git push -u origin my_shiny_feature
then go to your fork’s github page on the github website, select your feature branch and hit the “Pull Request” button in the top right corner. If you don’t get any feedback, bug us on the pylearn-dev mailing list.
When the your pull request have been merged, you can delete the branch from the github list of branch. That is usefull to don’t have too many that stay there!
git push origin :my_shiny_feature
You can keep you local repo up to date with central/master with those commands:
git checkout master
git fetch central
git merge central/master
If you want to fix a commit done in a pull request(i.e. fix small typo) to keep the history clean, you can do it like this:
git checkout branch
git commit --amend
git push -u origin my_shiny_feature:my_shiny_feature
See the coding style guideline here. The principal thing to know is that we follow the pep8 coding style.
We use git hooks provided in the project pygithooks to validate that commits respect pep8. This happens when each user commits, not when we push/merge to the Pylearn2 repository. Github doesn’t allow us to have code executed when we push to the repository. So we ask all contributors to use those hooks.
For historic reason, we currently don’t have all files respecting pep8. We decided to fix everything incrementally. So not all files respect it now. So we strongly suggest that you use the “increment” pygithooks config option to have a good workflow. See the pygithooks main page for how to set it up for Pylearn2 and how to enable this option.
Sometimes you may have commits in your feature branch that are not needed in the final pull request. There is a page that talks about this. In summary:
To checkout another user branch in his repo:
git remote add REPO_NAME HIS_REPO_PATH
git checkout -b LOCAL_BRANCH_NAME REPO_NAME/REMOVE_BRANCH_NAME
You can find move information and tips in the numpy development page.
$PYTHONPATH should contain a ”:”-separated list of paths, each of which contains one or several Python packages, in the order in which you would like Python to search for them. If a package has sub-packages of interest to you, do not add them to $PYTHONPATH: it is not portable, might shadow other packages or short-circuit important things in its __init__.
It is advisable to never import Pylearn2’s files from outside Pylearn2 itself (this is good advice for Python packages in general). Use from pylearn2 import module instead of import module. $PYTHONPATH should only contain paths to complete packages.
When you install a package, only the package name can be imported directly. If you want a sub-package, you must import it from the main package. That’s how it will work in 99.9% of installs because it is the default. Therefore, if you stray from this practice, your code will not be portable. Also, some ways to circumvent circular dependencies might make it so you have to import files in a certain order, which is best handled by the package’s own __init__.py.
Once you have completed these steps, you should run the by running nosetests from your checkout directory.
All tests should pass. If some test fails on your machine, you are encouraged to tell us what went wrong on the pylearn-dev mailing list.
To update your library to the latest revision, you should have a branch that tracks the main trunk. You can add one with:
git fetch central
git branch trunk central/master
Once you have such a branch, in order to update it, do:
git checkout trunk
git pull
Keep in mind that this branch should be “read-only”: if you want to patch Pylearn2, do it in another branch like described above.
You can instruct git to do color diff. For this, you need to add those lines in the file ~/.gitconfig
[color]
branch = auto
diff = auto
interactive = auto
status = auto
Each night we execute all the unit tests automatically. The result is sent by email to the theano-buildbot mailing list.
For more detail, see see.
To run all the tests with the same configuration as the buildbot, run this script:
pylearn2/misc/do_nightly_build
This function accepts arguments that it forward to nosetests. You can run only some tests or enable pdb by giving the equivalent nosetests parameters.