|
|
|
---
|
|
|
|
title: Developer guide
|
|
|
|
---
|
|
|
|
|
|
|
|
# IMPORTANT
|
|
|
|
|
|
|
|
If you have a local clone of the repository that **predates Feb. 19th, 2025, you must absolutely make a new clone**.
|
| ... | ... | @@ -251,7 +252,15 @@ If you followed the instructions on this page correctly, you should have created |
|
|
|
You can consult this MR at anytime to have an overview of all the commits pushed within that MR's scope, as well as all the changes between the latest commit and the branching commit.
|
|
|
|
The MR interface will be used for review by peers, to give feedback and ask questions about the proposed changes.
|
|
|
|
|
|
|
|
## Approval
|
|
|
|
Approval by one member of the DEAL lab is currently mandatory.
|
|
|
|
|
|
|
|
Approval will be granted if your changes:
|
|
|
|
- meet the criteria listed under [Good practices](#good-practices)
|
|
|
|
- are contributing to PASE in a meaningful way (i.e. address a standing issue, add a new feature, etc.)
|
|
|
|
- don't break the code (manual testing by the reviewer will occur ; unit tests will be implemented in the future)
|
|
|
|
|
|
|
|
## Merging
|
|
|
|
Once an MR is approved, you can prepare to merge it in the target branch (typically, feature branches merge into develop).
|
|
|
|
|
|
|
|
You can :
|
| ... | ... | @@ -263,6 +272,21 @@ You can : |
|
|
|
|
|
|
|
|
|
|
|
# Good practices
|
|
|
|
|
|
|
|
## Coding
|
|
|
|
- all additions to the code should follow commonly accepted coding practices (e.g. PEP8)
|
|
|
|
|
|
|
|
## Documentation
|
|
|
|
Document all of your work !
|
|
|
|
Your notes can be useful when submitting changes through a merge request or if you need to summarize your work over the course of a long feature branch.
|
|
|
|
|
|
|
|
Code should be commented so as to be understood by other developers and users, especially for code lines that can not be easily understood on the fly (typically complicated one-liners).
|
|
|
|
Don't hesitate to state the source of your code.
|
|
|
|
|
|
|
|
When creating a new modules, class, method or function, add a [docstring](https://peps.python.org/pep-0257/) describing the purpose of the piece of code.
|
|
|
|
[PEP257](https://peps.python.org/pep-0257/) documents the conventions related to Python docstrings. This is especially important because in the near future, the documentation of the framework will be automatically generated with Sphinx, a tool that parses docstrings to generate the building blocks of a static website.
|
|
|
|
|
|
|
|
## git
|
|
|
|
- **NEVER** add "all files" to git's tracked files (i.e. DO NOT use `git add .` or `git add -A` or `git add -A .`).
|
|
|
|
It can create confusion when going back to a previous commit and hide meaningful changes in a heap of modified or newly created files
|
|
|
|
- regularly pull `main` and `develop` branches from remote so you have the latest changes on your computer |
|
|
\ No newline at end of file |
