.. _development: Development =========== Working on front-end -------------------- To started development fron-end part of ``django-filer`` simply install all the packages over npm: ``npm install`` To compile and watch scss, run javascript unit-tests, jshint and jscs watchers: ``gulp`` To compile scss to css: ``gulp sass`` To run sass watcher: ``gulp sass:watch`` To run javascript linting and code styling analysis: ``gulp lint`` To run javascript linting and code styling analysis watcher: ``gulp lint:watch`` To run javascript linting: ``gulp jshint`` To run javascript code style analysis: ``gulp jscs`` To fix javascript code style errors: ``gulp jscs:fix`` To run javascript unit-tests: ``gulp tests:unit`` Contributing ------------ Claiming Issues ............... Since github issues does not support assigning an issue to a non collaborator (yet), please just add a comment on the issue to claim it. Code Guidelines ............... The code should be `PEP8`_ compliant. With the exception that the line width is not limited to 80, but to 120 characters. The `flake8`_ command can be very helpful (we run it as a separate env through `Tox` on `Travis`). If you want to check your changes for code style:: $ flake8 This runs the checks without line widths and other minor checks, it also ignores source files in the `migrations` and `tests` and some other folders. This is the last command to run before submitting a PR (that will run tests in all tox environments):: $ tox Another useful tool is `reindent`_. It fixes whitespace and indentation stuff:: $ reindent -n filer/models/filemodels.py Workflow ........ Fork -> Code -> Pull request django-filer uses the excellent `branching model `_ from `nvie`_. It is highly recommended to use the `git flow `_ extension that makes working with this branching model very easy. * fork `django-filer`_ on github * clone your fork ``git clone git@github.com:username/django-filer.git`` * ``cd django-filer`` * initialize git flow: ``git flow init`` (choose all the defaults) * ``git flow feature start my_feature_name`` creates a new branch called ``feature/my_feature_name`` based on ``master`` * ...code... ...code... ..commit.. ..commit.. * ``git flow feature publish`` creates a new branch remotely and pushes your changes * navigate to the feature branch on github and create a pull request to the ``master`` branch on ``divio/django-filer`` * after reviewing the changes may be merged into ``master`` for the release. If the feature branch is long running, it is good practice to merge in the current state of the ``master`` branch into the feature branch sometimes. This keeps the feature branch up to date and reduces the likeliness of merge conflicts once it is merged back into master. .. _`PEP8`: http://www.python.org/dev/peps/pep-0008 .. _`flake8`: http://pypi.python.org/pypi/flake8 .. _`reindent`: http://pypi.python.org/pypi/Reindent .. _`nvie`: http://nvie.com .. _`django-filer`: http://github.com/divio/django-filer