1- Contributing
2- ============
1+ .. _dev-guide-contributing :
2+
3+ Contributing to Zarr
4+ ====================
35
46Zarr is a community maintained project. We welcome contributions in the form of bug
57reports, bug fixes, documentation, enhancement proposals and more. This page provides
@@ -46,8 +48,7 @@ a bug report:
4648 interpreter can be obtained by running a Python interactive session, e.g.::
4749
4850 $ python
49- Python 3.6.1 (default, Mar 22 2017, 06:17:05)
50- [GCC 6.3.0 20170321] on linux
51+ Python 3.12.7 | packaged by conda-forge | (main, Oct 4 2024, 15:57:01) [Clang 17.0.6 ] on darwin
5152
5253Enhancement proposals
5354---------------------
@@ -73,7 +74,8 @@ The Zarr source code is hosted on GitHub at the following location:
7374* `https://github.com/zarr-developers/zarr-python <https://github.com/zarr-developers/zarr-python >`_
7475
7576You 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::
77+ the `"Fork" <https://github.com/zarr-developers/zarr-python/fork >`_ button.
78+ Then clone your fork to your local machine::
7779
7880 $ git clone [email protected] :your-user-name/zarr-python.git 7981 $ cd zarr-python
@@ -82,21 +84,21 @@ the "Fork" button. Then clone your fork to your local machine::
8284Creating a development environment
8385~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8486
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::
87+ To work with the Zarr source code, it is recommended to use
88+ `hatch <https://hatch.pypa.io/latest/index.html >`_ to create and manage development
89+ environments. Hatch will automatically install all Zarr dependencies using the same
90+ versions as are used by the core developers and continuous integration services.
91+ Assuming you have a Python 3 interpreter already installed, and you have cloned the
92+ Zarr source code and your current working directory is the root of the repository,
93+ you can do something like the following::
9194
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]
95+ $ pip install hatch
96+ $ hatch env show # list all available environments
9697
97- To verify that your development environment is working, you can run the unit tests::
98+ To verify that your development environment is working, you can run the unit tests
99+ for one of the test environments, e.g.::
98100
99- $ python -m pytest -v tests
101+ $ hatch env run --env test.py3.12-2.1-optional run
100102
101103Creating a branch
102104~~~~~~~~~~~~~~~~~
@@ -109,9 +111,7 @@ new, separate branch for each piece of work you want to do. E.g.::
109111
110112 git checkout main
111113 git fetch upstream
112- git rebase upstream/main
113- git push
114- git checkout -b shiny-new-feature
114+ git checkout -b shiny-new-feature upstream/main
115115 git push -u origin shiny-new-feature
116116
117117This changes your working directory to the 'shiny-new-feature' branch. Keep any changes in
@@ -129,54 +129,27 @@ merge conflicts, these need to be resolved before submitting a pull request.
129129Alternatively, you can merge the changes in from upstream/main instead of rebasing,
130130which can be simpler::
131131
132- git fetch upstream
133- git merge upstream/main
132+ git pull upstream main
134133
135134Again, any conflicts need to be resolved before submitting a pull request.
136135
137136Running the test suite
138137~~~~~~~~~~~~~~~~~~~~~~
139138
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::
139+ Zarr includes a suite of unit tests. The simplest way to run the unit tests
140+ is to activate your development environment
141+ (see `creating a development environment `_ above) and invoke::
167142
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 ``.
143+ $ hatch env run --env test.py3.12-2.1-optional run
174144
175145All tests are automatically run via GitHub Actions for every pull
176146request 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).
147+ also collected automatically via the Codecov service.
148+
149+ .. note ::
150+ Previous versions of Zarr-Python made extensive use of doctests. These tests were
151+ not maintained during the 3.0 refactor but may be brought back in the future.
152+ See :issue: `2614 ` for more details.
180153
181154Code standards - using pre-commit
182155~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -205,15 +178,17 @@ If you would like to skip the failing checks and push the code for further discu
205178the ``--no-verify `` option with ``git commit ``.
206179
207180
208-
209181Test coverage
210182~~~~~~~~~~~~~
211183
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::
184+ .. note ::
185+ Test coverage for Zarr-Python 3 is currently not at 100%. This is a known issue and help
186+ is welcome to bring test coverage back to 100%. See :issue: `2613 ` for more details.
187+
188+ Zarr strives to maintain 100% test coverage under the latest Python stable release
189+ Both unit tests and docstring doctests are included when computing coverage. Running::
215190
216- $ python -m pytest -v --cov=zarr --cov-config=pyproject.toml zarr
191+ $ hatch env run --env test.py3.12-2.1-optional run-coverage
217192
218193will automatically run the test suite with coverage and produce a coverage report.
219194This should be 100% before code can be accepted into the main code base.
@@ -229,28 +204,28 @@ Docstrings for user-facing classes and functions should follow the
229204`numpydoc
230205<https://numpydoc.readthedocs.io/en/stable/format.html#docstring-standard> `_
231206standard, 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
207+ should run and pass as doctests under Python 3.11.
237208
238209Zarr uses Sphinx for documentation, hosted on readthedocs.org. Documentation is
239210written in the RestructuredText markup language (.rst files) in the ``docs `` folder.
240211The 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 ``).
212+ and functions are included in the API documentation, under the ``docs/api `` folder
213+ using the `autodoc <https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html >`_
214+ extension to sphinx. Any new features or important usage information should be included in the
215+ user-guide (``docs/user-guide ``). Any changes should also be included in the release
216+ notes (``docs/developers/release.rst ``).
245217
246218The documentation can be built locally by running::
247219
248- $ cd docs
249- $ make clean; make html
250- $ open _build/html/index.html
220+ $ hatch --env docs run build
251221
252222The resulting built documentation will be available in the ``docs/_build/html `` folder.
253223
224+ Hatch can also be used to serve continuously updating version of the documentation
225+ during development at `http://0.0.0.0:8000/ <http://0.0.0.0:8000/ >`_. This can be done by running::
226+
227+ $ hatch --env docs run serve
228+
254229Development best practices, policies and procedures
255230---------------------------------------------------
256231
@@ -329,14 +304,7 @@ implements storage spec version 3, then the next library release should have ver
329304number 3.0.0. Note however that the major version number of the Zarr library may not
330305always correspond to the spec version number. For example, Zarr versions 2.x, 3.x, and
3313064.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.
307+ format compatibility, although they will not maintain API compatibility.
340308
341309When to make a release
342310~~~~~~~~~~~~~~~~~~~~~~
@@ -358,7 +326,7 @@ Release procedure
358326
359327.. note ::
360328
361- Most of the release process is now handled by github workflow which should
329+ Most of the release process is now handled by GitHub workflow which should
362330 automatically push a release to PyPI if a tag is pushed.
363331
364332Before releasing, make sure that all pull requests which will be
0 commit comments