Project Structure

The provided template is intended to support the development of simple python packages. Indeed, the proposed structure can be freely changed to better adapt to each project specificity: just consider it as a (tested) starting point to simplify an initial setup.

Here’s the minimal structure (at folder level, plus a few configuration files):

├── .github
│   ├── ISSUE_TEMPLATES
│   ├── workflows
├── conda
├── docs
├── package_name
│   ├── algorithms
│   ├── classes
│   ├── readwrite
│   ├── test
├── setup.py
├── README.md
├── requirements*.txt
├── environment.y’all
├── LICENSE
├── MANIFEST.in
├── .coveragerc
├── .readthedocs.yaml
└── .gitignore

In detail:

• .github/workflows : contains all the GitHub actions configuration files. An action is a set of instructions that needs to be triggered when a specific precondition verifies (e.g., packaging when a new release is created, check tests on push/demand);
• .github/ISSUE_TEMPLATES: templates for open issues issues, etc. etc.;
• conda/: configuration files needed to generate Anaconda package from the project (dependencies, pre/post actions…);
• docs/: python configuration (and markdown files) for generating sphinx configuration starting from docstrings;
• package_name/*: source folders organized to cover different functionalities exposed by the project;
• package_name/test/: unittests for the package functionalities;
• setup.py: setuptools entry point describing how to generate PyPi packages (installable using pip);
• requirements*.txt | environments.yaml: packaging dependencies (for Pypi|Conda);
• README.md | LICENSE | MANIFEST.md: textual files describing project aim|license|description files list;
• .coveragerc: selection of folders to check for unittest code coverage;
• .readthedocs.yaml: configuration files needed from ReadTheDocs to upload project documentation on their servers.