1
1

maintainers_guide.rst 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155
  1. =================
  2. Maintainers guide
  3. =================
  4. This guide is for Elephant maintainers only.
  5. Python 3
  6. --------
  7. Elephant should work with Python 2.7 and Python 3.
  8. So far, we have managed to write code that works with both Python 2 and 3.
  9. Mainly this involves and putting
  10. .. code-block:: python
  11. from __future__ import division, print_function, unicode_literals
  12. at the beginning of each source file. The most important thing to remember is
  13. to run tests with at least one version of Python 2 and at least one version of
  14. Python 3.
  15. If in doubt, `Porting to Python 3 <http://python3porting.com/>`_ by Lennart
  16. Regebro is an excellent resource.
  17. All code should conform as much as possible to
  18. `PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_.
  19. Each source file should have a copyright and a license note.
  20. Structure of the doc/ folder
  21. ----------------------------
  22. Documentation in Elephant is written exclusively using the ``sphinx`` package
  23. and resides in the ``doc`` folder, in addition to the docstrings contained of
  24. the ``elephant`` modules. In the following, we outline the main components of
  25. the Elephant documentation.
  26. Top-level documentation
  27. ~~~~~~~~~~~~~~~~~~~~~~~
  28. General information about the Elephant package and a gentle introduction are
  29. contained in various ``.rst`` files in the top-level directory of the Elephant
  30. package. Here, :file:`index.rst` is the central starting point, and the hierarchical
  31. document structure is specified using the ``toctree`` directives. In particular,
  32. these files contain a general introduction and tutorial on Elephant, the
  33. release notes of Elephant versions, and this development guide.
  34. Module and function reference
  35. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  36. All modules in Elephant are semi-automatically documented. To this end, for
  37. each module ``x`` a file ``doc/reference/x.rst`` exists with the following
  38. contents:
  39. .. code:: rst
  40. ============================
  41. `x` - Short descriptive name
  42. ============================
  43. .. automodule:: elephant.x
  44. This instructs Sphinx to add the module documentation in the module docstring
  45. into the file.
  46. The module docstring of ``elephant/x.py`` is also standardized in its structure:
  47. .. code:: rst
  48. .. include:: x-overview.rst
  49. .. current_module elephant.x
  50. Overview of Functions
  51. ---------------------
  52. <<Heading 1 to group functions (optional)>>
  53. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  54. .. autosummary::
  55. :toctree: toctree/x/
  56. function1
  57. function2
  58. <<Heading 2 to group functions (optional)>>
  59. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  60. .. autosummary::
  61. :toctree: toctree/x/
  62. function3
  63. function4
  64. Each module documentation starts with a short, understandable introduction to
  65. the functionality of the module, the "Overview". This text is written in a
  66. separate file residing in `doc/reference/x-overview.rst`, and is included on
  67. the first line. This keeps the docstring in the code short.
  68. Next, we specify the current module as `x`, in order to avoid confusion if
  69. a module uses submodules.
  70. In the following, all functions of the module are listed in an order that is
  71. intuitive for users. Where it makes sense, these functions can be thematically
  72. grouped using third-level headings. For small modules, no such headings are
  73. needed.
  74. Making a release
  75. ----------------
  76. 1. Increment the Elephant package version in :file:`elephant/VERSION`.
  77. 2. Add a section in :file:`doc/release_notes.rst`, describing in short the
  78. changes made from the previous release.
  79. 3. Check that the copyright statement (in :file:`LICENSE.txt`,
  80. :file:`README.md`, and :file:`doc/conf.py`) is correct.
  81. 4. If there is a new module do not forget to add the module name to the
  82. :file:`doc/modules.rst` and make a file with a short description in
  83. :file:`doc/reference/<modulename>.rst`.
  84. 5. Push the commit with release notes and version updated to github.
  85. 6. Remove :file:`elephant/spade_src/fim.so`. Otherwise, it'll be included in
  86. the built package (it should be downloaded at pip install).
  87. 7. Build a source package and upload it to PyPi.
  88. Build a source package (see `Packaging Python Projects
  89. <https://packaging.python.org/tutorials/packaging-projects/#generating-distribution-archives>`_)::
  90. $ pip install --user --upgrade twine
  91. $ python setup.py sdist
  92. To upload the package to `PyPI <http://pypi.python.org>`_
  93. (if you have the necessary permissions)::
  94. $ python -m twine upload dist/elephant-X.Y.Z.tar.gz
  95. 8. Finally, make a release on GitHub UI page and copy-paste the release notes.
  96. Then tag the release in the Git repository and push it::
  97. $ git tag <version>
  98. $ git push --tags upstream
  99. Here, version should be of the form ``vX.Y.Z``.