Skip to content

Commit f1064a3

Browse files
authored
docs: consolidate developer docs + update contributing page for v3 (#2593)
* docs: split tutorial into multiple user guide sections * docs: consolidate developer docs + update contributing page for v3 * second rev on dev docs * point to relevant issues on code coverage and testing * docs: consolidate developer docs + update contributing page for v3 * second rev on dev docs * point to relevant issues on code coverage and testing * fixup
1 parent 23beb8f commit f1064a3

File tree

6 files changed

+68
-89
lines changed

6 files changed

+68
-89
lines changed

docs/conf.py

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -105,6 +105,8 @@ def skip_submodules(
105105
"license": "https://github.com/zarr-developers/zarr-python/blob/main/LICENSE.txt",
106106
"tutorial": "user-guide",
107107
"getting-started": "quickstart",
108+
"release": "developers/release.html",
109+
"roadmap": "developers/roadmap.html",
108110
}
109111

110112
# The language for content autogenerated by Sphinx. Refer to documentation

docs/contributing.rst renamed to docs/developers/contributing.rst

Lines changed: 50 additions & 84 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
1-
Contributing
2-
============
1+
Contributing to Zarr
2+
====================
33

44
Zarr is a community maintained project. We welcome contributions in the form of bug
55
reports, bug fixes, documentation, enhancement proposals and more. This page provides
@@ -46,8 +46,7 @@ a bug report:
4646
interpreter can be obtained by running a Python interactive session, e.g.::
4747

4848
$ 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
5150

5251
Enhancement proposals
5352
---------------------
@@ -73,7 +72,8 @@ The Zarr source code is hosted on GitHub at the following location:
7372
* `https://github.com/zarr-developers/zarr-python <https://github.com/zarr-developers/zarr-python>`_
7473

7574
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::
7777

7878
$ git clone [email protected]:your-user-name/zarr-python.git
7979
$ cd zarr-python
@@ -82,21 +82,21 @@ the "Fork" button. Then clone your fork to your local machine::
8282
Creating a development environment
8383
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8484

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::
9192

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
9695

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.::
9898

99-
$ python -m pytest -v tests
99+
$ hatch env run --env test.py3.12-2.1-optional run
100100

101101
Creating a branch
102102
~~~~~~~~~~~~~~~~~
@@ -109,9 +109,7 @@ new, separate branch for each piece of work you want to do. E.g.::
109109

110110
git checkout main
111111
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
115113
git push -u origin shiny-new-feature
116114

117115
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.
129127
Alternatively, you can merge the changes in from upstream/main instead of rebasing,
130128
which can be simpler::
131129

132-
git fetch upstream
133-
git merge upstream/main
130+
git pull upstream main
134131

135132
Again, any conflicts need to be resolved before submitting a pull request.
136133

137134
Running the test suite
138135
~~~~~~~~~~~~~~~~~~~~~~
139136

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::
167140

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
174142

175143
All tests are automatically run via GitHub Actions for every pull
176144
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.
180151

181152
Code standards - using pre-commit
182153
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -205,15 +176,17 @@ If you would like to skip the failing checks and push the code for further discu
205176
the ``--no-verify`` option with ``git commit``.
206177

207178

208-
209179
Test coverage
210180
~~~~~~~~~~~~~
211181

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::
215188

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
217190

218191
will automatically run the test suite with coverage and produce a coverage report.
219192
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
229202
`numpydoc
230203
<https://numpydoc.readthedocs.io/en/stable/format.html#docstring-standard>`_
231204
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.
237206

238207
Zarr uses Sphinx for documentation, hosted on readthedocs.org. Documentation is
239208
written in the RestructuredText markup language (.rst files) in the ``docs`` folder.
240209
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``).
245215

246216
The documentation can be built locally by running::
247217

248-
$ cd docs
249-
$ make clean; make html
250-
$ open _build/html/index.html
218+
$ hatch --env docs run build
251219

252220
The resulting built documentation will be available in the ``docs/_build/html`` folder.
253221

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+
254227
Development best practices, policies and procedures
255228
---------------------------------------------------
256229

@@ -329,14 +302,7 @@ implements storage spec version 3, then the next library release should have ver
329302
number 3.0.0. Note however that the major version number of the Zarr library may not
330303
always correspond to the spec version number. For example, Zarr versions 2.x, 3.x, and
331304
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.
340306

341307
When to make a release
342308
~~~~~~~~~~~~~~~~~~~~~~
@@ -358,7 +324,7 @@ Release procedure
358324

359325
.. note::
360326

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
362328
automatically push a release to PyPI if a tag is pushed.
363329

364330
Before releasing, make sure that all pull requests which will be

docs/developers/index.rst

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
2+
Developer's Guide
3+
-----------------
4+
5+
.. toctree::
6+
:maxdepth: 1
7+
8+
contributing
9+
release
10+
roadmap
File renamed without changes.
File renamed without changes.

docs/index.rst

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -12,9 +12,8 @@ Zarr-Python
1212
installation
1313
user-guide/index
1414
api/index
15-
release
16-
contributing
17-
roadmap
15+
developers/index
16+
developers/release
1817
about
1918

2019
**Version**: |version|
@@ -93,11 +92,13 @@ Zarr is a file storage format for chunked, compressed, N-dimensional arrays base
9392
Contributor's Guide
9493
^^^^^^^^^^^^^^^^^^^
9594

96-
Want to contribute to Zarr? We welcome contributions in the form of bug reports, bug fixes, documentation, enhancement proposals and more. The contributing guidelines will guide you through the process of improving Zarr.
95+
Want to contribute to Zarr? We welcome contributions in the form of bug reports,
96+
bug fixes, documentation, enhancement proposals and more. The contributing guidelines
97+
will guide you through the process of improving Zarr.
9798

9899
+++
99100

100-
.. button-ref:: contributing
101+
.. button-ref:: developers/contributing
101102
:expand:
102103
:color: dark
103104
:click-parent:

0 commit comments

Comments
 (0)