|
| 1 | + |
| 2 | + |
| 3 | + |
| 4 | + |
| 5 | +## How to contribute to Cycode CLI |
| 6 | + |
| 7 | +The minimum version of Python that we support is 3.7. |
| 8 | +We recommend using this version for local development. |
| 9 | +But it’s fine to use a higher version without using new features from these versions. |
| 10 | +We prefer 3.8 because it comes with the support of Apple Silicon, and it is as low as possible. |
| 11 | + |
| 12 | +The project is under Poetry project management. |
| 13 | +To deal with it, you should install it on your system: |
| 14 | + |
| 15 | +Install Poetry (feel free to use Brew, etc): |
| 16 | + |
| 17 | +```shell |
| 18 | +curl -sSL https://install.python-poetry.org | python - -y |
| 19 | +``` |
| 20 | + |
| 21 | +Add Poetry to PATH if required. |
| 22 | + |
| 23 | +Add a plugin to support dynamic versioning from Git Tags: |
| 24 | + |
| 25 | +```shell |
| 26 | +poetry self add "poetry-dynamic-versioning[plugin]" |
| 27 | +``` |
| 28 | + |
| 29 | +Install dependencies of the project: |
| 30 | + |
| 31 | +```shell |
| 32 | +poetry install |
| 33 | +``` |
| 34 | + |
| 35 | +Check that the version is valid (not 0.0.0): |
| 36 | + |
| 37 | +```shell |
| 38 | +poetry version |
| 39 | +``` |
| 40 | + |
| 41 | +You are ready to write code! |
| 42 | + |
| 43 | +To run the project use: |
| 44 | + |
| 45 | +```shell |
| 46 | +poetry run cycode |
| 47 | +``` |
| 48 | + |
| 49 | +or main entry point in an activated virtual environment: |
| 50 | + |
| 51 | +```shell |
| 52 | +python cycode/cli/main.py |
| 53 | +``` |
| 54 | + |
| 55 | +### Code linting and formatting |
| 56 | + |
| 57 | +We use `ruff` and `ruff format`. |
| 58 | +It is configured well, so you don’t need to do anything. |
| 59 | +You can see all enabled rules in the `pyproject.toml` file. |
| 60 | +Both tests and the main codebase are checked. |
| 61 | +Try to avoid type annotations like `Any`, etc. |
| 62 | + |
| 63 | +GitHub Actions will check that your code is formatted well. You can run it locally: |
| 64 | + |
| 65 | +```shell |
| 66 | +# lint |
| 67 | +poetry run ruff . |
| 68 | +# format |
| 69 | +poetry run ruff format . |
| 70 | +``` |
| 71 | + |
| 72 | +Many rules support auto-fixing. You can run it with the `--fix` flag. |
| 73 | + |
| 74 | +### Branching and versioning |
| 75 | + |
| 76 | +We use the `main` branch as the main one. |
| 77 | +All development should be done in feature branches. |
| 78 | +When you are ready create a Pull Request to the `main` branch. |
| 79 | + |
| 80 | +Each commit in the `main` branch will be built and published to PyPI as a pre-release! |
| 81 | +Such builds could be installed with the `--pre` flag. For example: |
| 82 | + |
| 83 | +```shell |
| 84 | +pip install --pre cycode |
| 85 | +``` |
| 86 | + |
| 87 | +Also, you can select a specific version of the pre-release: |
| 88 | + |
| 89 | +```shell |
| 90 | +pip install cycode==1.7.2.dev6 |
| 91 | +``` |
| 92 | + |
| 93 | +We are using [Semantic Versioning](https://semver.org/) and the version is generated automatically from Git Tags. So, |
| 94 | +when you are ready to release a new version, you should create a new Git Tag. The version will be generated from it. |
| 95 | + |
| 96 | +Pre-release versions are generated on distance from the latest Git Tag. For example, if the latest Git Tag is `1.7.2`, |
| 97 | +then the next pre-release version will be `1.7.2.dev1`. |
| 98 | + |
| 99 | +We are using GitHub Releases to create Git Tags with changelogs. |
| 100 | +For changelogs, we are using a standard template |
| 101 | +of [Automatically generated release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes). |
| 102 | + |
| 103 | +### Testing |
| 104 | + |
| 105 | +We are using `pytest` for testing. You can run tests with: |
| 106 | + |
| 107 | +```shell |
| 108 | +poetry run pytest |
| 109 | +``` |
| 110 | + |
| 111 | +The library used for sending requests is [requests](https://github.com/psf/requests). |
| 112 | +To mock requests, we are using the [responses](https://github.com/getsentry/responses) library. |
| 113 | +All requests must be mocked. |
| 114 | + |
| 115 | +To see the code coverage of the project, you can run: |
| 116 | + |
| 117 | +```shell |
| 118 | +poetry run coverage run -m pytest . |
| 119 | +``` |
| 120 | + |
| 121 | +To generate the HTML report, you can run: |
| 122 | + |
| 123 | +```shell |
| 124 | +poetry run coverage html |
| 125 | +``` |
| 126 | + |
| 127 | +The report will be generated in the `htmlcov` folder. |
| 128 | + |
| 129 | +### Documentation |
| 130 | + |
| 131 | +Keep [README.md](README.md) up to date. |
| 132 | +All CLI commands are documented automatically if you add a docstring to the command. |
| 133 | +Clean up the changelog before release. |
| 134 | + |
| 135 | +### Publishing |
| 136 | + |
| 137 | +New versions are published automatically on the new GitHub Release. |
| 138 | +It uses the OpenID Connect publishing mechanism to upload on PyPI. |
| 139 | + |
| 140 | +[Homebrew formula](https://formulae.brew.sh/formula/cycode) is updated automatically on the new PyPI release. |
| 141 | + |
| 142 | +The CLI is also distributed as executable files for Linux, macOS, and Windows. |
| 143 | +It is powered by [PyInstaller](https://pyinstaller.org/) and the process is automated by GitHub Actions. |
| 144 | +These executables are attached to GitHub Releases as assets. |
| 145 | + |
| 146 | +To pack the project locally, you should run: |
| 147 | + |
| 148 | +```shell |
| 149 | +poetry build |
| 150 | +``` |
| 151 | + |
| 152 | +It will create a `dist` folder with the package (sdist and wheel). You can install it locally: |
| 153 | + |
| 154 | +```shell |
| 155 | +pip install dist/cycode-{version}-py3-none-any.whl |
| 156 | +``` |
| 157 | + |
| 158 | +To create an executable file locally, you should run: |
| 159 | + |
| 160 | +```shell |
| 161 | +poetry run pyinstaller pyinstaller.spec |
| 162 | +``` |
| 163 | + |
| 164 | +It will create an executable file for **the current platform** in the `dist` folder. |
0 commit comments