This document is primarily for developers.
If you plan to contribute to RotorHazard by opening a pull request for a bugfix or feature, please read the following text before you start. This will help you in submitting your contribution in a form that has a good chance of being accepted.
Ensure you understand the GitHub workflow: https://docs.github.com/en/get-started/quickstart/github-flow
Keep pull requests focused on one thing only, since this makes it easier to merge and test in a timely manner. A pull request should only make changes to the files that are needed for the modification.
If you need help with pull requests there are guides on GitHub here: GitHub - Creating a pull request
The main flow for a contributing is as follows:
- Login to GitHub, go to the RotorHazard repository and press
fork - Then using the command line/terminal on your computer:
git clone <url to YOUR fork> cd RotorHazardgit checkout maingit checkout -b my-new-code- Make changes
git add <files that have changed>git commitgit push origin my-new-code- Create a pull request using the GitHub web UI to merge your changes from your new branch into
RotorHazard/main - Repeat from step 4 for new other changes
The primary thing to remember is that separate pull requests should be created for separate branches. Never create a pull request from your main branch.
Once you have created the PR, every new commit/push in your branch will propagate from your fork into the PR in the main GitHub/RotorHazard repo. Checkout another branch first if you want something else.
Later, you can get the changes from the RotorHazard repository into your main branch by adding the RotorHazard repository as a git remote ("upstream") and merging from it as follows:
git remote add upstream https://github.com/RotorHazard/RotorHazard.gitgit checkout maingit pull upstream maingit push origin main(this is an optional step that will update your repository on GitHub)
If using Windows, TortoiseGit is highly recommended.
When code is added to an existing file, the new code should follow what's already there in terms of indentation (spaces vs tabs), braces, naming conventions, etc.
If a PR is modifying functionality, try to avoid unnecessary whitespace changes (i.e., adding/removing trailing spaces or newlines), as this makes it harder to see the functional changes. Improvements to whitespace and code style should be implemented with PRs that do only those things.
The "project" directory contains sample project files for the IntelliJ IDEA and Eclipse IDE editor/environments. To use them, copy the relevent files/directories to the top-most RotorHazard directory.
For IntelliJ IDEA, the Python plugin needs to be installed, see here for documentation. The "RotorHazard.iml" file and ".idea" directory define the project, which may be loaded via "File | Open" menu item. The JetBrains PyCharm IDE may also be used.
For Eclipse IDE, the PyDev extension needs to be installed. The ".project" and ".pydevproject" files define the project, which may be loaded via "File | Open Projects from File System..." in Eclipse.
The PyLint code analyzer is used to improve and reduce bugs in the code. All Python code in the project should be able to pass PyLint analysis with minimal errors and warnings. On Windows the package may be installed via the command: python -m pip install pylint
See here for enabling PyLint code analysis on Eclipse with PyDev. With its default settings PyLint will flag more warnings than we want to deal with, so we disable some of them by navigating (in Eclipse) to "Preferences | PyDev | Editor | Code Analysis | PyLint" and entering the following into the box under "Arguments to pass to the pylint command": --disable=broad-except,bare-except,logging-not-lazy,logging-format-interpolation,global-statement,try-except-raise,unused-argument
The batch/script files in the 'tools' directory may be used to run the PyLint analysis from the command line: 'pylintchk' checks for errors only, 'pylintchkw' checks for errors and warnings.