Initial split-off from Cerise Client

.editorconfig

@@ -0,0 +1,26 @@
+# EditorConfig is awesome: http://EditorConfig.org
+
+# top-most EditorConfig file
+root = true
+
+# Unix-style newlines with a newline ending every file
+[*]
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+charset = utf-8
+
+# 4 space indentation
+[*.{py,java,r,R}]
+indent_style = space
+indent_size = 4
+
+# 2 space indentation
+[*.{js,json,y{a,}ml,html,cwl}]
+indent_style = space
+indent_size = 2
+
+[*.{md,Rmd,rst}]
+trim_trailing_whitespace = false
+indent_style = space
+indent_size = 2

.gitignore

@@ -0,0 +1,23 @@
+*.py[cod]
+*.egg-info
+*.eggs
+.ipynb_checkpoints
+
+build
+dist
+.cache
+__pycache__
+
+htmlcov
+.coverage
+coverage.xml
+.pytest_cache
+
+docs/_build
+docs/apidocs
+
+# ide
+.idea
+.eclipse
+.vscode
+**.swp

.prospector.yml

@@ -0,0 +1,29 @@
+# prospector configuration file
+
+---
+
+output-format: grouped
+
+strictness: medium
+doc-warnings: false
+test-warnings: true
+member-warnings: false
+
+ignore-paths:
+  - docs
+
+pyroma:
+    run: true
+
+pep8:
+    full: true
+
+pep257:
+    disable: [
+        # Disable because not part of PEP257 official convention:
+        # see http://pep257.readthedocs.io/en/latest/error_codes.html
+        D203,  # 1 blank line required before class docstring
+        D212,  # Multi-line docstring summary should start at the first line
+        D213,  # Multi-line docstring summary should start at the second line
+        D404,  # First word of the docstring should not be This
+    ]

.travis.yml

@@ -0,0 +1,13 @@
+# Config file for automatic testing at travis-ci.org
+language: python
+python:
+  - "3.4"
+  - "3.5"
+  - "3.6"
+
+# command to install dependencies
+install:
+  - pip install -r requirements.txt
+
+# command to run tests
+script: python setup.py test

CHANGELOG.rst

@@ -0,0 +1,14 @@
+###########
+Change Log
+###########
+
+All notable changes to this project will be documented in this file.
+This project adheres to `Semantic Versioning <http://semver.org/>`_.
+
+[Unreleased]
+************
+
+Added
+-----
+
+* Empty Python project directory structure

CODE_OF_CONDUCT.rst

@@ -0,0 +1,79 @@
+###############################################################################
+Contributor Covenant Code of Conduct
+###############################################################################
+
+Our Pledge
+**********
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+education, socio-economic status, nationality, personal appearance, race,
+religion, or sexual identity and orientation.
+
+Our Standards
+*************
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+Our Responsibilities
+********************
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+Scope
+*****
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+Enforcement
+***********
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+Attribution
+***********
+
+This Code of Conduct is adapted from the `Contributor Covenant <https://www.contributor-covenant.org>`_, version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

CONTRIBUTING.rst

@@ -0,0 +1,44 @@
+############################
+Contributing guidelines
+############################
+
+We welcome any kind of contribution to our software, from simple comment or question to a full fledged `pull request <https://help.github.com/articles/about-pull-requests/>`_. Please read and follow our `Code of Conduct <CODE_OF_CONDUCT.rst>`_.
+
+A contribution can be one of the following cases:
+
+1. you have a question;
+1. you think you may have found a bug (including unexpected behavior);
+1. you want to make some kind of change to the code base (e.g. to fix a bug, to add a new feature, to update documentation).
+
+The sections below outline the steps in each case.
+
+You have a question
+*******************
+
+1. use the search functionality `here <https://github.com/MD-Studio/cerise_manager/issues>`__ to see if someone already filed the same issue;
+1. if your issue search did not yield any relevant results, make a new issue;
+1. apply the "Question" label; apply other labels when relevant.
+
+You think you may have found a bug
+**********************************
+
+1. use the search functionality `here <https://github.com/MD-Studio/cerise_manager/issues>`__ to see if someone already filed the same issue;
+1. if your issue search did not yield any relevant results, make a new issue, making sure to provide enough information to the rest of the community to understand the cause and context of the problem. Depending on the issue, you may want to include:
+    - the `SHA hashcode <https://help.github.com/articles/autolinked-references-and-urls/#commit-shas>`_ of the commit that is causing your problem;
+    - some identifying information (name and version number) for dependencies you're using;
+    - information about the operating system;
+1. apply relevant labels to the newly created issue.
+
+You want to make some kind of change to the code base
+*****************************************************
+
+1. (**important**) announce your plan to the rest of the community *before you start working*. This announcement should be in the form of a (new) issue;
+1. (**important**) wait until some kind of consensus is reached about your idea being a good idea;
+1. if needed, fork the repository to your own Github profile and create your own feature branch off of the latest master commit. While working on your feature branch, make sure to stay up to date with the master branch by pulling in changes, possibly from the 'upstream' repository (follow the instructions `here <https://help.github.com/articles/configuring-a-remote-for-a-fork/>`__ and `here <https://help.github.com/articles/syncing-a-fork/>`__);
+1. make sure the existing tests still work by running ``python setup.py test``;
+1. add your own tests (if necessary);
+1. update or expand the documentation;
+1. `push <http://rogerdudler.github.io/git-guide/>`_ your feature branch to (your fork of) the Cerise Manager repository on GitHub;
+1. create the pull request, e.g. following the instructions `here <https://help.github.com/articles/creating-a-pull-request/>`__.
+
+In case you feel like you've made a valuable contribution, but you don't know how to write or run tests for it, or how to generate the documentation: don't let this discourage you from making the pull request; we can help you! Just go ahead and submit the pull request, but keep in mind that you might be asked to append additional commits to your pull request.