1
- Contributing
2
- ============
1
+ Contributing to Zarr
2
+ ====================
3
3
4
4
Zarr is a community maintained project. We welcome contributions in the form of bug
5
5
reports, bug fixes, documentation, enhancement proposals and more. This page provides
@@ -46,8 +46,7 @@ a bug report:
46
46
interpreter can be obtained by running a Python interactive session, e.g.::
47
47
48
48
$ python
49
- Python 3.6.1 (default, Mar 22 2017, 06:17:05)
50
- [GCC 6.3.0 20170321] on linux
49
+ Python 3.12.7 | packaged by conda-forge | (main, Oct 4 2024, 15:57:01) [Clang 17.0.6 ] on darwin
51
50
52
51
Enhancement proposals
53
52
---------------------
@@ -73,7 +72,8 @@ The Zarr source code is hosted on GitHub at the following location:
73
72
* `https://github.com/zarr-developers/zarr-python <https://github.com/zarr-developers/zarr-python >`_
74
73
75
74
You will need your own fork to work on the code. Go to the link above and hit
76
- the "Fork" button. Then clone your fork to your local machine::
75
+ the `"Fork" <https://github.com/zarr-developers/zarr-python/fork >`_ button.
76
+ Then clone your fork to your local machine::
77
77
78
78
$ git clone [email protected] :your-user-name/zarr-python.git
79
79
$ cd zarr-python
@@ -82,21 +82,21 @@ the "Fork" button. Then clone your fork to your local machine::
82
82
Creating a development environment
83
83
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
84
84
85
- To work with the Zarr source code, it is recommended to set up a Python virtual
86
- environment and install all Zarr dependencies using the same versions as are used by
87
- the core developers and continuous integration services. Assuming you have a Python
88
- 3 interpreter already installed, and you have cloned the Zarr source code and your
89
- current working directory is the root of the repository, you can do something like
90
- the following::
85
+ To work with the Zarr source code, it is recommended to use
86
+ `hatch <https://hatch.pypa.io/latest/index.html >`_ to create and manage development
87
+ environments. Hatch will automatically install all Zarr dependencies using the same
88
+ versions as are used by the core developers and continuous integration services.
89
+ Assuming you have a Python 3 interpreter already installed, and you have cloned the
90
+ Zarr source code and your current working directory is the root of the repository,
91
+ you can do something like the following::
91
92
92
- $ mkdir -p ~/pyenv/zarr-dev
93
- $ python -m venv ~/pyenv/zarr-dev
94
- $ source ~/pyenv/zarr-dev/bin/activate
95
- $ pip install -e .[test,docs]
93
+ $ pip install hatch
94
+ $ hatch env show # list all available environments
96
95
97
- To verify that your development environment is working, you can run the unit tests::
96
+ To verify that your development environment is working, you can run the unit tests
97
+ for one of the test environments, e.g.::
98
98
99
- $ python -m pytest -v tests
99
+ $ hatch env run --env test.py3.12-2.1-optional run
100
100
101
101
Creating a branch
102
102
~~~~~~~~~~~~~~~~~
@@ -109,9 +109,7 @@ new, separate branch for each piece of work you want to do. E.g.::
109
109
110
110
git checkout main
111
111
git fetch upstream
112
- git rebase upstream/main
113
- git push
114
- git checkout -b shiny-new-feature
112
+ git checkout -b shiny-new-feature upstream/main
115
113
git push -u origin shiny-new-feature
116
114
117
115
This changes your working directory to the 'shiny-new-feature' branch. Keep any changes in
@@ -129,54 +127,27 @@ merge conflicts, these need to be resolved before submitting a pull request.
129
127
Alternatively, you can merge the changes in from upstream/main instead of rebasing,
130
128
which can be simpler::
131
129
132
- git fetch upstream
133
- git merge upstream/main
130
+ git pull upstream main
134
131
135
132
Again, any conflicts need to be resolved before submitting a pull request.
136
133
137
134
Running the test suite
138
135
~~~~~~~~~~~~~~~~~~~~~~
139
136
140
- Zarr includes a suite of unit tests, as well as doctests included in
141
- function and class docstrings and in the tutorial and storage
142
- spec. The simplest way to run the unit tests is to activate your
143
- development environment (see `creating a development environment `_ above)
144
- and invoke::
145
-
146
- $ python -m pytest -v zarr
147
-
148
- Some tests require optional dependencies to be installed, otherwise
149
- the tests will be skipped. To install all optional dependencies, run::
150
-
151
- $ pip install pytest-doctestplus
152
-
153
- To also run the doctests within docstrings (requires optional
154
- dependencies to be installed), run::
155
-
156
- $ python -m pytest -v --doctest-plus zarr
157
-
158
- To run the doctests within the tutorial and storage spec (requires
159
- optional dependencies to be installed), run::
160
-
161
- $ python -m doctest -o NORMALIZE_WHITESPACE -o ELLIPSIS docs/tutorial.rst docs/spec/v2.rst
162
-
163
- Note that some tests also require storage services to be running
164
- locally. To run the Azure Blob Service storage tests, run an Azure
165
- storage emulator (e.g., azurite) and set the environment variable
166
- ``ZARR_TEST_ABS=1 ``. If you're using Docker to run azurite, start the service with::
137
+ Zarr includes a suite of unit tests. The simplest way to run the unit tests
138
+ is to activate your development environment
139
+ (see `creating a development environment `_ above) and invoke::
167
140
168
- docker run --rm -p 10000:10000 mcr.microsoft.com/azure-storage/azurite azurite-blob --loose --blobHost 0.0.0.0
169
-
170
- To run the Mongo DB storage tests, run a Mongo
171
- server locally and set the environment variable ``ZARR_TEST_MONGO=1 ``.
172
- To run the Redis storage tests, run a Redis server locally on port
173
- 6379 and set the environment variable ``ZARR_TEST_REDIS=1 ``.
141
+ $ hatch env run --env test.py3.12-2.1-optional run
174
142
175
143
All tests are automatically run via GitHub Actions for every pull
176
144
request and must pass before code can be accepted. Test coverage is
177
- also collected automatically via the Codecov service, and total
178
- coverage over all builds must be 100% (although individual builds
179
- may be lower due to Python 2/3 or other differences).
145
+ also collected automatically via the Codecov service.
146
+
147
+ .. note ::
148
+ Previous versions of Zarr-Python made extensive use of doctests. These tests were
149
+ not maintained during the 3.0 refactor but may be brought back in the future.
150
+ See :issue: `2614 ` for more details.
180
151
181
152
Code standards - using pre-commit
182
153
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -205,15 +176,17 @@ If you would like to skip the failing checks and push the code for further discu
205
176
the ``--no-verify `` option with ``git commit ``.
206
177
207
178
208
-
209
179
Test coverage
210
180
~~~~~~~~~~~~~
211
181
212
- Zarr maintains 100% test coverage under the latest Python stable release (currently
213
- Python 3.8). Both unit tests and docstring doctests are included when computing
214
- coverage. Running::
182
+ .. note ::
183
+ Test coverage for Zarr-Python 3 is currently not at 100%. This is a known issue and help
184
+ is welcome to bring test coverage back to 100%. See :issue: `2613 ` for more details.
185
+
186
+ Zarr strives to maintain 100% test coverage under the latest Python stable release
187
+ Both unit tests and docstring doctests are included when computing coverage. Running::
215
188
216
- $ python -m pytest -v --cov=zarr --cov-config=pyproject.toml zarr
189
+ $ hatch env run --env test.py3.12-2.1-optional run-coverage
217
190
218
191
will automatically run the test suite with coverage and produce a coverage report.
219
192
This should be 100% before code can be accepted into the main code base.
@@ -229,28 +202,28 @@ Docstrings for user-facing classes and functions should follow the
229
202
`numpydoc
230
203
<https://numpydoc.readthedocs.io/en/stable/format.html#docstring-standard> `_
231
204
standard, including sections for Parameters and Examples. All examples
232
- should run and pass as doctests under Python 3.8. To run doctests,
233
- activate your development environment, install optional requirements,
234
- and run::
235
-
236
- $ python -m pytest -v --doctest-plus tests
205
+ should run and pass as doctests under Python 3.11.
237
206
238
207
Zarr uses Sphinx for documentation, hosted on readthedocs.org. Documentation is
239
208
written in the RestructuredText markup language (.rst files) in the ``docs `` folder.
240
209
The documentation consists both of prose and API documentation. All user-facing classes
241
- and functions should be included in the API documentation, under the ``docs/api ``
242
- folder. Any new features or important usage information should be included in the
243
- tutorial (``docs/tutorial.rst ``). Any changes should also be included in the release
244
- notes (``docs/release.rst ``).
210
+ and functions are included in the API documentation, under the ``docs/api `` folder
211
+ using the `autodoc <https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html >`_
212
+ extension to sphinx. Any new features or important usage information should be included in the
213
+ user-guide (``docs/user-guide ``). Any changes should also be included in the release
214
+ notes (``docs/developers/release.rst ``).
245
215
246
216
The documentation can be built locally by running::
247
217
248
- $ cd docs
249
- $ make clean; make html
250
- $ open _build/html/index.html
218
+ $ hatch --env docs run build
251
219
252
220
The resulting built documentation will be available in the ``docs/_build/html `` folder.
253
221
222
+ Hatch can also be used to serve continuously updating version of the documentation
223
+ during development at `http://0.0.0.0:8000/ <http://0.0.0.0:8000/ >`_. This can be done by running::
224
+
225
+ $ hatch --env docs run serve
226
+
254
227
Development best practices, policies and procedures
255
228
---------------------------------------------------
256
229
@@ -329,14 +302,7 @@ implements storage spec version 3, then the next library release should have ver
329
302
number 3.0.0. Note however that the major version number of the Zarr library may not
330
303
always correspond to the spec version number. For example, Zarr versions 2.x, 3.x, and
331
304
4.x might all implement the same version of the storage spec and thus maintain data
332
- format compatibility, although they will not maintain API compatibility. The version number
333
- of the storage specification that is currently implemented is stored under the
334
- ``zarr.meta.ZARR_FORMAT `` variable.
335
-
336
- Note that the Zarr test suite includes a data fixture and tests to try and ensure that
337
- data format compatibility is not accidentally broken. See the
338
- :func: `test_format_compatibility ` function in the :mod: `tests.test_storage ` module
339
- for details.
305
+ format compatibility, although they will not maintain API compatibility.
340
306
341
307
When to make a release
342
308
~~~~~~~~~~~~~~~~~~~~~~
@@ -358,7 +324,7 @@ Release procedure
358
324
359
325
.. note ::
360
326
361
- Most of the release process is now handled by github workflow which should
327
+ Most of the release process is now handled by GitHub workflow which should
362
328
automatically push a release to PyPI if a tag is pushed.
363
329
364
330
Before releasing, make sure that all pull requests which will be
0 commit comments