Skip to content

Latest commit

 

History

History
170 lines (111 loc) · 7.67 KB

project_setup.rst

File metadata and controls

170 lines (111 loc) · 7.67 KB
Raw

Project Setup

Here we provide some details about the project setup. Most of the choices are explained in the guide. Links to the relevant sections are included below. Feel free to remove this text when the development of the software package takes off.

For a quick reference on software development, we refer to the software guide checklist.

Version control

Once your Python package is created, put it under version control! We recommend using git and github.

cd ci_for_science
git init
git add -A
git commit

To put your code on github, follow this tutorial.

Python versions

This repository is set up with Python versions:

  • 3.6
  • 3.7

Add or remove Python versions based on project requirements. See the guide for more information about Python versions.

Package management and dependencies

You can use either pip or conda for installing dependencies and package management. This repository does not force you to use one or the other, as project requirements differ. For advice on what to use, please check the relevant section of the guide.

  • Dependencies should be added to setup.py in the install_requires list.

Packaging/One command install

You can distribute your code using pipy or conda. Again, the project template does not enforce the use of either one. The guide can help you decide which tool to use for packaging.

If you decide to use pypi for distributing you code, you can configure travis to upload to pypi when you make a release. If you specified your pypi user name during generation of this package, the .travis.yml file contains a section that looks like:

deploy:
  provider: pypi
  user: no_pypi_travis_deployment
  password:
    secure: FIXME; see README for more info
 on:
    tags: true
    branch: master

Before this actually works, you need to add an encrypted password for your pypi account. The travis documentation specifies how to do this.

Testing and code coverage

  • Tests should be put in the tests folder.
  • The tests folder contains:
    • Example tests that you should replace with your own meaningful tests (file: test_ci_for_science)
    • A test that checks whether your code conforms to the Python style guide (PEP 8) (file: test_lint.py)
  • The testing framework used is PyTest
  • Tests can be run with python setup.py test
    • This is configured in setup.py and setup.cfg
  • Use Travis CI to automatically run tests and to test using multiple Python versions
  • TODO: add something about code quality/coverage tool?
  • Relevant section in the guide

Documentation

  • Documentation should be put in the docs folder. The contents have been generated using sphinx-quickstart (Sphinx version 1.6.5).
  • We recommend writing the documentation using Restructured Text (reST) and Google style docstrings.
  • The documentation is set up with the Read the Docs Sphinx Theme.
  • To generate html documentation run python setup.py build_sphinx
    • This is configured in setup.cfg
    • Alternatively, run make html in the docs folder.
  • The docs/_templates directory contains an (empty) .gitignore file, to be able to add it to the repository. This file can be safely removed (or you can just leave it there).
  • To put the documentation on Read the Docs, log in to your Read the Docs account, and import the repository (under 'My Projects').
    • Include the link to the documentation in this README_.
  • Relevant section in the guide

Coding style conventions and code quality

  • Check your code style with prospector
  • You may need run pip install .[dev] first, to install the required dependencies
  • You can use yapf to fix the readability of your code style and isort to format and group your imports
  • Relevant section in the guide

Package version number

  • We recommend using semantic versioning.
  • For convenience, the package version is stored in a single place: ci_for_science/__version__.py. For updating the version number, you only have to change this file.
  • Don't forget to update the version number before making a release!

Logging

  • We recommend using the logging module for getting useful information from your module (instead of using print).
  • The project is set up with a logging example.
  • Relevant section in the guide

CHANGELOG.rst

CITATION.cff

  • To allow others to cite your software, add a CITATION.cff file
  • It only makes sense to do this once there is something to cite (e.g., a software release with a DOI).
  • Follow the making software citable section in the guide.

CODE_OF_CONDUCT.rst

CONTRIBUTING.rst

MANIFEST.in

NOTICE