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
|
.. developers:
RDFLib developers guide
=======================
Introduction
------------
This document describes the process and conventions to follow when
developing RDFLib code.
Please be as Pythonic as possible (:pep:`8`).
Code should be formatted using `black <https://github.com/psf/black>`_.
While not yet mandatory, it will be required in the future (6.0.0+).1
Use Black v21.9b0, with the black.toml config file provided.
Code should also pass `flake8 <https://github.com/psf/black>`_ linting
and `mypy <http://mypy-lang.org/>`_ type checking.
Any new functionality being added to RDFLib should have doc tests and
unit tests. Tests should be added for any functionality being changed
that currently does not have any doc tests or unit tests. And all the
tests should be run before committing changes to make sure the changes
did not break anything.
If you add a new cool feature, consider also adding an example in ``./examples``
Running tests
-------------
Run tests with `pytest <https://docs.pytest.org/en/latest/>`_:
.. code-block:: bash
$ pip install -r requirements.txt -r requirements.dev.txt
$ pytest
Specific tests can be run by file name. For example:
.. code-block:: bash
$ pytest test/test_graph.py
Running static checks
---------------------
Check formatting with `black <https://github.com/psf/black>`_:
.. code-block:: bash
python -m black --config black.toml --check ./rdflib
Check style and conventions with `flake8 <https://github.com/psf/black>`_:
.. code-block:: bash
python -m flake8 rdflib
Check types with `mypy <http://mypy-lang.org/>`_:
.. code-block:: bash
python -m mypy --show-error-context --show-error-codes rdflib
Writing documentation
---------------------
We use sphinx for generating HTML docs, see :ref:`docs`.
Continuous Integration
----------------------
We used Drone for CI, see:
https://drone.rdflib.ashs.dev/RDFLib/rdflib
If you make a pull-request to RDFLib on GitHub, Drone will automatically test your code and we will only merge code
passing all tests.
Please do *not* commit tests you know will fail, even if you're just pointing out a bug. If you commit such tests,
flag them as expecting to fail.
Compatibility
-------------
RDFLib 5.0.0 maintained compatibility with python versions 2.7, 3.4, 3.5, 3.6, 3.7.
The latest 6.0.0 release and subsequent will only support Python 3.7 and newer.
Releasing
---------
Set to-be-released version number in :file:`rdflib/__init__.py` and
:file:`README.md`. Check date in :file:`LICENSE`.
Add :file:`CHANGELOG.md` entry.
Commit this change. It's preferable make the release tag via
https://github.com/RDFLib/rdflib/releases/new ::
Our Tag versions aren't started with 'v', so just use a plain 5.0.0 like
version. Release title is like "RDFLib 5.0.0", the description a copy of your
:file:`CHANGELOG.md` entry.
This gives us a nice release page like this::
https://github.com/RDFLib/rdflib/releases/tag/4.2.2
If for whatever reason you don't want to take this approach, the old one is::
Tagging the release commit with::
git tag -am 'tagged version' X.X.X
When pushing, remember to do::
git push --tags
No matter how you create the release tag, remember to upload tarball to pypi with::
rm -r dist/X.X.X[.-]* # delete all previous builds for this release, just in case
rm -r build
python setup.py sdist
python setup.py bdist_wheel
ls dist
# upload with twine
# WARNING: once uploaded can never be modified, only deleted!
twine upload dist/rdflib-X.X.X[.-]*
Set new dev version number in the above locations, i.e. next release `-dev`: ``5.0.1-dev`` and commit again.
Tweet, email mailing list and inform members in the chat.
|
