Scheduled service maintenance on November 22


On Friday, November 22, 2024, between 06:00 CET and 18:00 CET, GIN services will undergo planned maintenance. Extended service interruptions should be expected. We will try to keep downtimes to a minimum, but recommend that users avoid critical tasks, large data uploads, or DOI requests during this time.

We apologize for any inconvenience.

developers_guide.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300
  1. =================
  2. Developers' guide
  3. =================
  4. These instructions are for developing on a Unix-like platform, e.g. Linux or
  5. Mac OS X, with the bash shell. If you develop on Windows, please get in touch.
  6. Mailing lists
  7. -------------
  8. General discussion of Neo development takes place in the `NeuralEnsemble Google
  9. group`_.
  10. Discussion of issues specific to a particular ticket in the issue tracker
  11. should take place on the tracker.
  12. Using the issue tracker
  13. -----------------------
  14. If you find a bug in Neo, please create a new ticket on the `issue tracker`_,
  15. setting the type to "defect".
  16. Choose a name that is as specific as possible to the problem you've found, and
  17. in the description give as much information as you think is necessary to
  18. recreate the problem. The best way to do this is to create the shortest
  19. possible Python script that demonstrates the problem, and attach the file to
  20. the ticket.
  21. If you have an idea for an improvement to Neo, create a ticket with type
  22. "enhancement". If you already have an implementation of the idea, create a
  23. patch (see below) and attach it to the ticket.
  24. To keep track of changes to the code and to tickets, you can register for
  25. a GitHub account and then set to watch the repository at `GitHub Repository`_
  26. (see https://help.github.com/articles/watching-repositories/).
  27. Requirements
  28. ------------
  29. * Python_ 2.7, 3.4 or later
  30. * numpy_ >= 1.7.1
  31. * quantities_ >= 0.9.0
  32. * nose_ >= 0.11.1 (for running tests)
  33. * Sphinx_ >= 0.6.4 (for building documentation)
  34. * (optional) tox_ >= 0.9 (makes it easier to test with multiple Python versions)
  35. * (optional) coverage_ >= 2.85 (for measuring test coverage)
  36. * (optional) scipy >= 0.12 (for MatlabIO)
  37. * (optional) h5py >= 2.5 (for KwikIO, NeoHdf5IO)
  38. We strongly recommend you develop within a virtual environment (from virtualenv, venv or conda).
  39. It is best to have at least one virtual environment with Python 2.7 and one with Python 3.x.
  40. Getting the source code
  41. -----------------------
  42. We use the Git version control system. The best way to contribute is through
  43. GitHub_. You will first need a GitHub account, and you should then fork the
  44. repository at `GitHub Repository`_
  45. (see http://help.github.com/fork-a-repo/).
  46. To get a local copy of the repository::
  47. $ cd /some/directory
  48. $ git clone git@github.com:<username>/python-neo.git
  49. Now you need to make sure that the ``neo`` package is on your PYTHONPATH.
  50. You can do this either by installing Neo::
  51. $ cd python-neo
  52. $ python setup.py install
  53. $ python3 setup.py install
  54. (if you do this, you will have to re-run ``setup.py install`` any time you make
  55. changes to the code) *or* by creating symbolic links from somewhere on your
  56. PYTHONPATH, for example::
  57. $ ln -s python-neo/neo
  58. $ export PYTHONPATH=/some/directory:${PYTHONPATH}
  59. An alternate solution is to install Neo with the *develop* option, this avoids
  60. reinstalling when there are changes in the code::
  61. $ sudo python setup.py develop
  62. or using the "-e" option to pip::
  63. $ pip install -e python-neo
  64. To update to the latest version from the repository::
  65. $ git pull
  66. Running the test suite
  67. ----------------------
  68. Before you make any changes, run the test suite to make sure all the tests pass
  69. on your system::
  70. $ cd neo/test
  71. With Python 2.7 or 3.x::
  72. $ python -m unittest discover
  73. $ python3 -m unittest discover
  74. If you have nose installed::
  75. $ nosetests
  76. At the end, if you see "OK", then all the tests
  77. passed (or were skipped because certain dependencies are not installed),
  78. otherwise it will report on tests that failed or produced errors.
  79. To run tests from an individual file::
  80. $ python test_analogsignal.py
  81. $ python3 test_analogsignal.py
  82. Writing tests
  83. -------------
  84. You should try to write automated tests for any new code that you add. If you
  85. have found a bug and want to fix it, first write a test that isolates the bug
  86. (and that therefore fails with the existing codebase). Then apply your fix and
  87. check that the test now passes.
  88. To see how well the tests cover the code base, run::
  89. $ nosetests --with-coverage --cover-package=neo --cover-erase
  90. Working on the documentation
  91. ----------------------------
  92. All modules, classes, functions, and methods (including private and subclassed
  93. builtin methods) should have docstrings.
  94. Please see `PEP257`_ for a description of docstring conventions.
  95. Module docstrings should explain briefly what functions or classes are present.
  96. Detailed descriptions can be left for the docstrings of the respective
  97. functions or classes. Private functions do not need to be explained here.
  98. Class docstrings should include an explanation of the purpose of the class
  99. and, when applicable, how it relates to standard neuroscientific data.
  100. They should also include at least one example, which should be written
  101. so it can be run as-is from a clean newly-started Python interactive session
  102. (that means all imports should be included). Finally, they should include
  103. a list of all arguments, attributes, and properties, with explanations.
  104. Properties that return data calculated from other data should explain what
  105. calculation is done. A list of methods is not needed, since documentation
  106. will be generated from the method docstrings.
  107. Method and function docstrings should include an explanation for what the
  108. method or function does. If this may not be clear, one or more examples may
  109. be included. Examples that are only a few lines do not need to include
  110. imports or setup, but more complicated examples should have them.
  111. Examples can be tested easily using the iPython `%doctest_mode` magic. This will
  112. strip >>> and ... from the beginning of each line of the example, so the
  113. example can be copied and pasted as-is.
  114. The documentation is written in `reStructuredText`_, using the `Sphinx`_
  115. documentation system. Any mention of another Neo module, class, attribute,
  116. method, or function should be properly marked up so automatic
  117. links can be generated. The same goes for quantities or numpy.
  118. To build the documentation::
  119. $ cd python-neo/doc
  120. $ make html
  121. Then open `some/directory/python-neo/doc/build/html/index.html` in your browser.
  122. Committing your changes
  123. -----------------------
  124. Once you are happy with your changes, **run the test suite again to check
  125. that you have not introduced any new bugs**. It is also recommended to check
  126. your code with a code checking program, such as `pyflakes`_ or `flake8`_. Then
  127. you can commit them to your local repository::
  128. $ git commit -m 'informative commit message'
  129. If this is your first commit to the project, please add your name and
  130. affiliation/employer to :file:`doc/source/authors.rst`
  131. You can then push your changes to your online repository on GitHub::
  132. $ git push
  133. Once you think your changes are ready to be included in the main Neo repository,
  134. open a pull request on GitHub
  135. (see https://help.github.com/articles/using-pull-requests).
  136. Python version
  137. --------------
  138. Neo core should work with both Python 2.7 and Python 3 (version 3.4 or newer).
  139. Neo IO modules should ideally work with both Python 2 and 3, but certain
  140. modules may only work with one or the other (see :doc:`install`).
  141. So far, we have managed to write code that works with both Python 2 and 3.
  142. Mainly this involves avoiding the ``print`` statement (use ``logging.info``
  143. instead), and putting ``from __future__ import division`` at the beginning of
  144. any file that uses division.
  145. If in doubt, `Porting to Python 3`_ by Lennart Regebro is an excellent resource.
  146. The most important thing to remember is to run tests with at least one version
  147. of Python 2 and at least one version of Python 3. There is generally no problem
  148. in having multiple versions of Python installed on your computer at once: e.g.,
  149. on Ubuntu Python 2 is available as `python` and Python 3 as `python3`, while
  150. on Arch Linux Python 2 is `python2` and Python 3 `python`. See `PEP394`_ for
  151. more on this. Using virtual environments makes this very straightforward.
  152. Coding standards and style
  153. --------------------------
  154. All code should conform as much as possible to `PEP 8`_, and should run with
  155. Python 2.7, and 3.4 or newer.
  156. You can use the `pep8`_ program to check the code for PEP 8 conformity.
  157. You can also use `flake8`_, which combines pep8 and pyflakes.
  158. However, the pep8 and flake8 programs do not check for all PEP 8 issues.
  159. In particular, they do not check that the import statements are in the
  160. correct order.
  161. Also, please do not use ``from xyz import *``. This is slow, can lead to
  162. conflicts, and makes it difficult for code analysis software.
  163. Making a release
  164. ----------------
  165. .. TODO: discuss branching/tagging policy.
  166. Add a section in :file:`/doc/source/whatisnew.rst` for the release.
  167. First check that the version string (in :file:`neo/version.py`) is correct.
  168. To build a source package::
  169. $ python setup.py sdist
  170. Tag the release in the Git repository and push it::
  171. $ git tag <version>
  172. $ git push --tags origin
  173. $ git push --tags upstream
  174. To upload the package to `PyPI`_ (currently Samuel Garcia, Andrew Davison,
  175. Michael Denker and Julia Sprenger have the necessary permissions to do this)::
  176. $ twine upload dist/neo-0.X.Y.tar.gz
  177. .. talk about readthedocs
  178. .. make a release branch
  179. If you want to develop your own IO module
  180. -----------------------------------------
  181. See :ref:`io_dev_guide` for implementation of a new IO.
  182. .. _Python: http://www.python.org
  183. .. _nose: http://somethingaboutorange.com/mrl/projects/nose/
  184. .. _unittest2: http://pypi.python.org/pypi/unittest2
  185. .. _Setuptools: https://pypi.python.org/pypi/setuptools/
  186. .. _tox: http://codespeak.net/tox/
  187. .. _coverage: http://nedbatchelder.com/code/coverage/
  188. .. _`PEP 8`: http://www.python.org/dev/peps/pep-0008/
  189. .. _`issue tracker`: https://github.com/NeuralEnsemble/python-neo/issues
  190. .. _`Porting to Python 3`: http://python3porting.com/
  191. .. _`NeuralEnsemble Google group`: http://groups.google.com/group/neuralensemble
  192. .. _reStructuredText: http://docutils.sourceforge.net/rst.html
  193. .. _Sphinx: http://sphinx.pocoo.org/
  194. .. _numpy: http://numpy.scipy.org/
  195. .. _quantities: http://pypi.python.org/pypi/quantities
  196. .. _PEP257: http://www.python.org/dev/peps/pep-0257/
  197. .. _PEP394: http://www.python.org/dev/peps/pep-0394/
  198. .. _PyPI: http://pypi.python.org
  199. .. _GitHub: http://github.com
  200. .. _`GitHub Repository`: https://github.com/NeuralEnsemble/python-neo/
  201. .. _pep8: https://pypi.python.org/pypi/pep8
  202. .. _flake8: https://pypi.python.org/pypi/flake8/
  203. .. _pyflakes: https://pypi.python.org/pypi/pyflakes/