forked from cloudmesh/client
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CONTRIBUTING
57 lines (37 loc) · 2.1 KB
/
CONTRIBUTING
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
The project is open source and if you like you can help. Here are some contribution guidelines:
* we use the Apache 2.0 licence
* we recommend to use pycharm for editing and utlize the `Inspect
Code` feature regularly on the files you modify and fix the sensible
pep8 warnings. Look at other warnings and errors
* use ``.format`` instead of ``%`` in print statements
* use ``from __future__ import print_function`` at the beginning of the file and use
``print("msg")`` instead of ``print msg``
* use as much python 3 like code but use python 2
* use ``class name(object):`` and not just ``class name:``
* use ``Console.error`` when printing errors if you develop a command
for the commandline
* use ``Console.ok`` when printing something that confirms the action
is ok. In many cases you may not want o use print, but
Console.ok. Please note that Console.ok, takesa string argument.
* use ``ConfigDict`` when reading yaml files. It even allows you to
read a yaml file in order, make changes to it and write it back
* use nosetests for testing your programs
An example is provided in ``tests/test_sample.py``::
nosetests -v --nocapture tests/test_sample.py
you can copy this to ``tests/test_yourfile.py`` and then replace in
that file the occurrence of ``_sample`` with ``_yourfile``
make sure to create meaningful tests.
* the documentation is write in RST http://sphinx-doc.org/rest.html
* look at http://python-future.org/compatible_idioms.html for tips to
make python 2 look more like python 3. Be careful with dicts to
make them not inefficient.
* we are using https://pypi.python.org/pypi/gitchangelog for creating
changelogs automatically. Thus you need to use a prefix in any
commit. It includes the type and the user for which the commit is
relevant. Examples are::
chg: usr: simple changes relevant for users (spelling, ...)
fix: usr: major changes for users
new: usr: new feature for users
chg: dev: simple changes relevant for developers (spelling, ...)
fix: dev: major changes for developers
new: dev: new feature for developers