forked from tqdm/tqdm
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CONTRIBUTE
266 lines (187 loc) · 6.44 KB
/
CONTRIBUTE
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
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
HOW TO CONTRIBUTE TO TQDM
=========================
This file describes how to
- contribute changes to the project, and
- upload released to the pypi repository.
Most of the management commands have been directly placed inside the
Makefile:
```
make [<alias>] # on UNIX-like environments
python setup.py make [<alias>] # if make is unavailable
```
Use the alias `help` (or leave blank) to list all available aliases.
HOW TO COMMIT CONTRIBUTIONS
---------------------------
Contributions to the project are made using the "Fork & Pull" model. The
typical steps would be:
1. create an account on [github](https://github.com)
2. fork [tqdm](https://github.com/tqdm/tqdm)
3. make a local clone: `git clone https://github.com/your_account/tqdm.git`
4. make changes on the local copy
5. test (see below) and commit changes `git commit -a -m "my message"`
6. `push` to your github account: `git push origin`
7. create a Pull Request (PR) from your github fork
(go to your fork's webpage and click on "Pull Request."
You can then add a message to describe your proposal.)
TESTING
-------
To test functionality (such as before submitting a Pull
Request), there are a number of unit tests.
Standard unit tests
~~~~~~~~~~~~~~~~~~~
The standard way to run the tests:
- install `tox`
- `cd` to the root of the `tqdm` directory (in the same folder as this file)
- run the following command:
```
[python setup.py] make test
# or:
tox --skip-missing-interpreters
```
This will build the module and run the tests in a virtual environment.
Errors and coverage rates will be output to the console/log. (Ignore missing
interpreters errors - these are due to the local machine missing certain
versions of Python.)
Note: to install all versions of the Python interpreter that are specified
in [tox.ini](https://raw.githubusercontent.com/tqdm/tqdm/master/tox.ini),
you can use `MiniConda` to install a minimal setup. You must also make sure
that each distribution has an alias to call the Python interpreter:
`python27` for Python 2.7's interpreter, `python32` for Python 3.2's, etc.
Alternative unit tests with Nose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alternatively, use `nose` to run the tests just for the current Python version:
- install `nose` and `flake8`
- run the following command:
```
[python setup.py] make alltests
```
MANAGE A NEW RELEASE
=====================
This section is intended for the project's maintainers and describes
how to build and upload a new release. Once again,
`[python setup.py] make [<alias>]` will help.
SEMANTIC VERSIONING
-------------------
The tqdm repository managers should:
- regularly bump the version number in the file
[_version.py](https://raw.githubusercontent.com/tqdm/tqdm/master/tqdm/_version.py)
- follow the [Semantic Versioning](http://semver.org/) convention
- take care of this (instead of users) to avoid PR conflicts
solely due to the version file bumping
Note: tools can be used to automate this process, such as
[bumpversion](https://github.com/peritus/bumpversion) or
[python-semanticversion](https://github.com/rbarrois/python-semanticversion/).
CHECKING SETUP.PY
-----------------
To check that the `setup.py` file is compliant with PyPi requirements (e.g.
version number; reStructuredText in README.rst) use:
```
[python setup.py] make testsetup
```
To upload just metadata (including overwriting mistakenly uploaded metadata)
to PyPi, use:
```
[python setup.py] make pypimeta
```
MERGING PULL REQUESTS
---------------------
This section describes how to cleanly merge PRs.
1 Rebase
~~~~~~~~
From your project repository, merge and test
(replace `pr-branch-name` as appropriate):
```
git fetch origin
git checkout -b pr-branch-name origin/pr-branch-name
git rebase master
```
If there are conflicts:
```
git mergetool
git rebase --continue
```
2 Push
~~~~~~
Update branch with the rebased history:
```
git push origin pr-branch-name --force
```
Non maintainers can stop here.
Note: NEVER just `git push --force` (this will push all local branches,
overwriting remotes).
3 Merge
~~~~~~~
```
git checkout master
git merge --no-ff pr-branch-name
```
4 Test
~~~~~~
```
[python setup.py] make alltests
```
5 Version
~~~~~~~~~
Modify tqdm/_version.py and ammend the last (merge) commit:
```
git add tqdm/_version.py
git commit --amend # Add "+ bump version" in the commit message
```
6 Push to master
~~~~~~~~~~~~~~~~
```
git push origin master
```
BUILDING A RELEASE AND UPLOADING TO PYPI
----------------------------------------
Formally publishing requires additional steps: testing and tagging.
Test
~~~~
- ensure that all online CI tests have passed
- check `setup.py` and `MANIFEST.in` - which define the packaging
process and info that will be uploaded to [pypi](pypi.python.org) -
using `[python setup.py] make installdev`
Tag
~~~
- ensure the version has been bumped, committed **and** tagged.
The tag format is `v{major}.{minor}.{patch}`, for example: `v4.4.1`.
The current commit's tag is used in the version checking process.
If the current commit is not tagged appropriately, the version will
display as `v{major}.{minor}.{patch}-{commit_hash}`.
Upload
~~~~~~
Build tqdm into a distributable python package:
```
[python setup.py] make build
```
This will generate several builds in the `dist/` folder. On non-windows
machines the windows `exe` installer may fail to build. This is normal.
Finally, upload everything to pypi. This can be done easily using the
[twine](https://github.com/pypa/twine) module:
```
[python setup.py] make pypi
```
Also, the new release can (should) be added to `github` by creating a new
release from the web interface; uploading packages from the `dist/` folder
created by `[python setup.py] make build`.
Notes
~~~~~
- you can also test on the pypi test servers `testpypi.python.org/pypi`
before the real deployment
- in case of a mistake, you can delete an uploaded release on pypi, but you
cannot re-upload another with the same version number
- in case of a mistake in the metadata on pypi (e.g. bad README),
updating just the metadata is possible: `[python setup.py] make pypimeta`
QUICK DEV SUMMARY
-----------------
For expereinced devs, once happy with local master:
1. bump version in `tqdm/_version.py`
2. test (`[python setup.py] make alltests`)
3. `git commit [--amend] # -m "bump version"`
4. `git push`
5. wait for tests to pass
a) in case of failure, fix and go back to (2)
6. `git tag vM.m.p && git push --tags`
7. `[python setup.py] make distclean`
8. `[python setup.py] make build`
9. `[python setup.py] make pypi`