Karim shoair commited on
Commit
e4d251c
·
1 Parent(s): bb64364

docs: Enhance CONTRIBUTING rules with PR guidelines and updates

Browse files

Added guidelines for making pull requests and updated documentation on building and testing.

Files changed (1) hide show
  1. CONTRIBUTING.md +19 -17
CONTRIBUTING.md CHANGED
@@ -13,6 +13,17 @@ There are many ways to contribute to Scrapling. Here are some of them:
13
  - Join the [Discord community](https://discord.gg/EMgGbDceNQ) and share your ideas on how to improve Scrapling. We’re always open to suggestions.
14
  - If you are not a developer, perhaps you would like to help with translating the [documentation](https://github.com/D4Vinci/Scrapling/tree/docs)?
15
 
 
 
 
 
 
 
 
 
 
 
 
16
 
17
  ## Finding work
18
 
@@ -26,7 +37,7 @@ If you have decided to make a contribution to Scrapling, but you do not know wha
26
  ## Coding style
27
  Please follow these coding conventions as we do when writing code for Scrapling:
28
  - We use [pre-commit](https://pre-commit.com/) to automatically address simple code issues before every commit, so please install it and run `pre-commit install` to set it up. This will install hooks to run [ruff](https://docs.astral.sh/ruff/), [bandit](https://github.com/PyCQA/bandit), and [vermin](https://github.com/netromdk/vermin) on every commit. We are currently using a workflow to automatically run these tools on every PR, so if your code doesn't pass these checks, the PR will be rejected.
29
- - We use type hints for better code clarity and [pyright](https://github.com/microsoft/pyright) for static type checking, which depends on the type hints, of course.
30
  - We use the conventional commit messages format as [here](https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13#types), so for example, we use the following prefixes for commit messages:
31
 
32
  | Prefix | When to use it |
@@ -63,11 +74,12 @@ pip3 install git+https://github.com/D4Vinci/Scrapling.git@dev
63
  ```
64
 
65
  ## Building Documentation
66
- Documentation is built using [MkDocs](https://www.mkdocs.org/). You can build it locally using the following commands:
67
  ```bash
68
- pip install mkdocs-material
69
- mkdocs serve # Local preview
70
- mkdocs build # Build the static site
 
71
  ```
72
 
73
  ## Tests
@@ -80,8 +92,8 @@ Scrapling includes a comprehensive test suite that can be executed with pytest.
80
  rootdir: /Users/<redacted>/scrapling
81
  configfile: pytest.ini
82
  plugins: asyncio-1.2.0, anyio-4.11.0, xdist-3.8.0, httpbin-2.1.0, cov-7.0.0
83
- asyncio: mode=Mode.AUTO, debug=False, asyncio_default_fixture_loop_scope=function, asyncio_default_test_loop_scope=function
84
- 10 workers [271 items]
85
  scheduling tests via LoadScheduling
86
 
87
  ...<shortened>...
@@ -94,13 +106,3 @@ Bonus: You can also see the test coverage with the `pytest` plugin below
94
  ```bash
95
  pytest --cov=scrapling tests/
96
  ```
97
-
98
- ## Making a Pull Request
99
- To ensure that your PR gets accepted, please make sure that your PR is based on the latest changes from the dev branch and that it satisfies the following requirements:
100
-
101
- - The PR should be made against the [**dev**](https://github.com/D4Vinci/Scrapling/tree/dev) branch of Scrapling. Any PR made against the main branch will be rejected.
102
- - The code should be passing all available tests. We use tox with GitHub's CI to run the current tests on all supported Python versions for every code-related commit.
103
- - The code should be passing all code quality checks we mentioned above. We are using GitHub's CI to enforce the code style checks performed by pre-commit. If you were using the pre-commit hooks we discussed above, you should not see any issues when committing your changes.
104
- - Make your changes, keep the code clean with an explanation of any part that might be vague, and remember to create a separate virtual environment for this project.
105
- - If you are adding a new feature, please add tests for it.
106
- - If you are fixing a bug, please add code with the PR that reproduces the bug.
 
13
  - Join the [Discord community](https://discord.gg/EMgGbDceNQ) and share your ideas on how to improve Scrapling. We’re always open to suggestions.
14
  - If you are not a developer, perhaps you would like to help with translating the [documentation](https://github.com/D4Vinci/Scrapling/tree/docs)?
15
 
16
+ ## Making a Pull Request
17
+ To ensure that your PR gets accepted, please make sure that your PR is based on the latest changes from the dev branch and that it satisfies the following requirements:
18
+
19
+ - **The PR must be made against the [**dev**](https://github.com/D4Vinci/Scrapling/tree/dev) branch of Scrapling. Any PR made against the main branch will be rejected.**
20
+ - **The code should be passing all available tests. We use tox with GitHub's CI to run the current tests on all supported Python versions for every code-related commit.**
21
+ - **The code should be passing all code quality checks like `mypy` and `pyright`. We are using GitHub's CI to enforce code style checks as well.**
22
+ - **Make your changes, keep the code clean with an explanation of any part that might be vague, and remember to create a separate virtual environment for this project.**
23
+ - If you are adding a new feature, please add tests for it.
24
+ - If you are fixing a bug, please add code with the PR that reproduces the bug.
25
+ - Please follow the rules and coding style rules we explain below.
26
+
27
 
28
  ## Finding work
29
 
 
37
  ## Coding style
38
  Please follow these coding conventions as we do when writing code for Scrapling:
39
  - We use [pre-commit](https://pre-commit.com/) to automatically address simple code issues before every commit, so please install it and run `pre-commit install` to set it up. This will install hooks to run [ruff](https://docs.astral.sh/ruff/), [bandit](https://github.com/PyCQA/bandit), and [vermin](https://github.com/netromdk/vermin) on every commit. We are currently using a workflow to automatically run these tools on every PR, so if your code doesn't pass these checks, the PR will be rejected.
40
+ - We use type hints for better code clarity and [pyright](https://github.com/microsoft/pyright)/[mypy](https://github.com/python/mypy) for static type checking. If your code isn't acceptable by those tools, your PR won't pass the code quality rule.
41
  - We use the conventional commit messages format as [here](https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13#types), so for example, we use the following prefixes for commit messages:
42
 
43
  | Prefix | When to use it |
 
74
  ```
75
 
76
  ## Building Documentation
77
+ Documentation is built using [Zensical](https://zensical.org/). You can build it locally using the following commands:
78
  ```bash
79
+ pip install zensical
80
+ pip install -r docs/requirements.txt
81
+ zensical build --clean # Build the static site
82
+ zensical serve # Local preview
83
  ```
84
 
85
  ## Tests
 
92
  rootdir: /Users/<redacted>/scrapling
93
  configfile: pytest.ini
94
  plugins: asyncio-1.2.0, anyio-4.11.0, xdist-3.8.0, httpbin-2.1.0, cov-7.0.0
95
+ asyncio: mode=Mode.STRICT, asyncio_default_fixture_loop_scope=function, asyncio_default_test_loop_scope=function
96
+ 10 workers [515 items]
97
  scheduling tests via LoadScheduling
98
 
99
  ...<shortened>...
 
106
  ```bash
107
  pytest --cov=scrapling tests/
108
  ```