1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
# Contributing to Vulture
## Creating and cloning a fork
Fork the Vulture repository on GitHub by clicking the "fork" button on the
top right. Then clone your fork to your local machine:
$ git clone https://github.com/USERNAME/vulture.git # Use your GitHub username.
$ cd vulture
## Installation
We recommend using a Python virtual environment to isolate the
installation of vulture.
### Setting up the virtual environment
You can read more about `virtualenv` in the [virtualenv
documentation](http://virtualenv.readthedocs.org).
To install the `virtualenv` package using `pip`, run:
$ python3 -m pip install virtualenv
Now you can create your own environment (named `vulture_dev`):
$ virtualenv vulture_dev
Now, whenever you work on the project, activate the corresponding
environment.
- On **Unix-based** systems, this can be done with:
$ source vulture_dev/bin/activate
- And on **Windows** this is done with:
$ vulture_dev\scripts\activate
To leave the virtual environment use:
(vulture_dev)$ deactivate
### Installing vulture
Navigate to your cloned `vulture` directory, and run the following to
install in development mode:
$ pip install --editable .
### Installing test tools
Vulture uses tox for testing. You can read more about it in the [tox
documentation](https://tox.readthedocs.io).
To install `tox`, run:
$ pip install tox
It's also recommended that you use `pre-commit` to catch style errors
early:
$ pip install pre-commit
$ pre-commit install
## Coding standards
### Creating a new branch
To start working on a pull request, create a new branch to work on. You
should never develop on your main branch because your main branch
should always be synchronized with the main repo’s main branch, which
is challenging if it has new commits. Create a branch using:
$ git checkout -b your-new-branch
#### Naming branches
Branch names should describe the feature/issue that you want to work on,
but at the same time be short.
### Commits
Each commit should be atomic and its message should adequately describe
the change in a clear manner. Use imperative, e.g., "Fix issue12." instead
of "Fixed issue12.". Please make sure that you only fix the issue at hand
or implement the desired new feature instead of making "drive-by" changes
like adding type hints.
### Formating and linting
Run `pre-commit` using:
$ pre-commit run --all-files
## Testing
Run `tox` using:
$ tox
## Pull requests
### How to send a pull request?
Push your changes to your fork with:
$ git push --set-upstream origin BRANCHNAME
Then visit your fork on GitHub, change the branch to the one you committed
to, and click the `New Pull Request` button.
### Follow-up
In case your PR needs to be updated (tests fail or reviewer requests some
changes), update it by committing on top of your branch. It is not
necessary to amend your previous commit, since we will usually squash all
commits when merging anyway.
### Feedback
Take reviewer feedback positively. It's unlikely for a PR to be merged on
the first attempt, but don’t worry that’s just how it works. It helps to
keep the code clean.
|
