|
1 | 1 | Style guide:
|
2 |
| -- PEP-8 |
3 |
| -- Python 3.7+ compatible code |
| 2 | +- PEP-8 (as implemented by the `black` code formatting tool) |
| 3 | +- Python 3.6+ compatible code |
4 | 4 | - PEP-484 type hints
|
5 |
| -- Vertically align the type hints in function definitions |
6 | 5 |
|
7 |
| -The development is done using ``git``, we encourage you to get familiar with it. |
| 6 | +The development is done using `git`, we encourage you to get familiar with it. |
8 | 7 | Here's a rough guide (improvements are welcome!)
|
9 | 8 | To get the code and start working on the changes you can start a console and:
|
10 |
| -- Clone the cwltool: ``git clone https://github.com/common-workflow-language/cwltool.git`` |
11 |
| -- Switch to cwltool directory: ``cd cwltool`` |
| 9 | +- Clone the cwltool: `git clone https://github.com/common-workflow-language/cwltool.git` |
| 10 | +- Switch to cwltool directory: `cd cwltool` |
12 | 11 |
|
13 |
| -In order to contribute to the development of ``cwltool``, the source code needs to pass the test before your changes are accepted. |
14 |
| -There are a couple ways to test the code with your changes: let `tox` manage installation and test running in virtual environments, or do it manually (preferably in a virtual environment): |
15 |
| -- Install ``tox`` preferably using the OS' package manager, otherwise it can be installed with ``pip install --user -U tox`` |
| 12 | +In order to contribute to the development of `cwltool`, the source code needs to |
| 13 | +pass the test before your changes are accepted. There are a couple ways to test |
| 14 | +the code with your changes: let `tox` manage installation and test running in |
| 15 | +virtual environments, or do it manually (preferably in a virtual environment): |
| 16 | +- Install `tox` preferably using the OS' package manager, otherwise it can be |
| 17 | + installed with `pip install --user -U tox` |
16 | 18 | - Make your changes to the code and add tests for new cool things you're adding!
|
17 |
| -- Run the tests with the command ``tox``, it's recommended to use some parameters as tox will try to run all the checks in all available python interpreters. |
18 |
| -- The important tests to run are ``unit tests`` and ``type tests``. |
19 |
| - To run these two in Python 3.7, we can tell tox to run only those tests by running: ``tox -e py37-unit,py37-mypy2,py37-mypy3``. |
20 |
| -- Run ``tox -l`` to see all available tests and runtimes |
| 19 | +- Run the tests with the command `tox`, it's recommended to use some parameters |
| 20 | + as tox will try to run all the checks in all available python interpreters. |
| 21 | +- The important tests to run are "unit tests" and "type tests". |
| 22 | + To run these two in Python 3.7 (for example), we can tell tox to run only those |
| 23 | + tests by running: `tox -e py37-mypy`. (the `mypy` tox target also runs the |
| 24 | + unit tests; to just run the type checker use `make mypy` as shown below) |
| 25 | +- Run `tox -l` to see all available tests and runtimes |
21 | 26 |
|
22 | 27 | For the more traditional workflow:
|
23 |
| -- Create a virtual environment: ``python3 -m venv cwltool`` |
24 |
| -- To begin using the virtual environment, it needs to be activated: ``source bin/activate`` |
25 |
| -- To check if you have the virtual environment set up: ``which python`` and it should point to python executable in your virtualenv |
26 |
| -- Install cwltool: ``pip install -e .`` |
27 |
| -- Check the version which might be different from the version installed in general on any system: ``cwltool --version`` |
| 28 | +- Create a virtual environment: `python3 -m venv cwltool` |
| 29 | + (if you have multiple version of Python installed, then you can replace `python3` |
| 30 | + in this command with the version you want to use, `python3.10` for example) |
| 31 | +- To begin using the virtual environment, it needs to be activated: `source venv/bin/activate` |
| 32 | +- To check if you have the virtual environment set up: `which python` |
| 33 | + and it should point to python executable in your virtualenv |
| 34 | +- Install cwltool in development mode, along with development tools: |
| 35 | + `make install-dep dev` |
| 36 | +- Check the `cwltool` version which might be different from the version installed in |
| 37 | + general on your system: `cwltool --version` |
28 | 38 | - Make your changes to the code and add tests for new cool things you're adding!
|
29 |
| -- Run the unit-tests to see : ``python setup.py test`` |
30 |
| -- After you're done working on ``cwltool``, you can deactivate the virtual environment: ``deactivate`` |
| 39 | +- Run the unit-tests to see : `make test` |
| 40 | +- After you're done working on `cwltool`, you can deactivate the virtual |
| 41 | + environment: `deactivate` |
31 | 42 |
|
32 |
| -When tests are passing, you can simply commit and create a PR on ``cwltool`` repo |
| 43 | +Before you commit your code (or at least before you push to GitHub) it is |
| 44 | +recommended to run `make cleanup` |
| 45 | +(which is a shortcut for `make sort_imports format flake8 diff_pydocstyle_report`) |
| 46 | +to fix common issues and point out any remaining code formatting issues |
| 47 | +that cannot be fixed automatically. |
| 48 | + |
| 49 | +When tests are passing, you can create git commits in a new branch and push to |
| 50 | +GitHub to make a pull request on `cwltool` repo |
| 51 | + |
| 52 | +Useful `make` commands: |
| 53 | +The `make` commands below can help you to install the dependencies, format and test your code |
| 54 | + |
| 55 | +- `make help` to show the list of commands that can be used with the make function |
| 56 | +- `make install-dep` will install the dependencies needed by `cwltool` |
| 57 | +- `make format` will clean up your code according to the accepted python standard |
| 58 | +- `make test` will perform the tests of `cwltool` (can take a while to run all tests) |
| 59 | +- `make sort_imports` will clean up and sort your import statements |
| 60 | +- `make remove_unused_imports` will remove any unneeded `import` statements |
| 61 | +- `make flake8` will catch format issues that `make format` cannot fix automatically |
| 62 | +- `make diff_pydocstyle_report` check Python docstring style for changed files only |
| 63 | +- `make diff-cover` to run the tests and point out which lines of code that have been |
| 64 | + changed as compared to the `main` branch are missing test coverage. This is also calculated |
| 65 | + automatically after all the automatic tests run when you open a Pull Request on GitHub; |
| 66 | + running it locally can help you confirm that any changes or additions |
| 67 | + to the tests are sufficient before pushing to GitHub. |
| 68 | +- `make cleanup` is a shortcut for `make sort_imports format flake8 diff_pydocstyle_report` |
0 commit comments