zarr-developers
diff --git a/‎docs/release.rst
Lines changed: 24 additions & 3 deletions b/‎docs/release.rst
Lines changed: 24 additions & 3 deletions
diff --git a/‎docs/tutorial.rst
Lines changed: 24 additions & 12 deletions b/‎docs/tutorial.rst
Lines changed: 24 additions & 12 deletions
@@ -9,6 +9,27 @@ Unreleased
 Bug fixes
 ~~~~~~~~~
 
+* Fix bug that made it impossible to create an ``FSStore`` on unlistable filesystems
+  (e.g. some HTTP servers).
+  By :user:`Ryan Abernathey <rabernat>`; :issue:`993`.
+
+Enhancements
+~~~~~~~~~~~~
+
+* **Create FSStore from an existing fsspec filesystem**. If you have created
+  an fsspec filesystem outside of Zarr, you can now pass it as a keyword
+  argument to ``FSStore``.
+  By :user:`Ryan Abernathey <rabernat>`.
+
+
+.. _release_2.11.1:
+
+2.11.3
+------
+
+Bug fixes
+~~~~~~~~~
+
 * Changes the default value of ``write_empty_chunks`` to ``True`` to prevent
   unanticipated data losses when the data types do not have a proper default
   value when empty chunks are read back in.
@@ -319,7 +340,7 @@ Bug fixes
 
 * FSStore: default to normalize_keys=False
   By :user:`Josh Moore <joshmoore>`; :issue:`755`.
-* ABSStore: compatibility with ``azure.storage.python>=12`` 
+* ABSStore: compatibility with ``azure.storage.python>=12``
   By :user:`Tom Augspurger <tomaugspurger>`; :issue:`618`
 
 
@@ -484,7 +505,7 @@ This release will be the last to support Python 3.5, next version of Zarr will b
 
 * `DirectoryStore` now uses `os.scandir`, which should make listing large store
   faster, :issue:`563`
-  
+
 * Remove a few remaining Python 2-isms.
   By :user:`Poruri Sai Rahul <rahulporuri>`; :issue:`393`.
 
@@ -504,7 +525,7 @@ This release will be the last to support Python 3.5, next version of Zarr will b
   ``zarr.errors``  have been replaced by ``ValueError`` subclasses. The corresponding
   ``err_*`` function have been removed. :issue:`590`, :issue:`614`)
 
-* Improve consistency of terminology regarding arrays and datasets in the 
+* Improve consistency of terminology regarding arrays and datasets in the
   documentation.
   By :user:`Josh Moore <joshmoore>`; :issue:`571`.
 
 
@@ -758,7 +758,7 @@ databases. The :class:`zarr.storage.RedisStore` class interfaces `Redis <https:/
 (an in memory data structure store), and the :class:`zarr.storage.MongoDB` class interfaces
 with `MongoDB <https://www.mongodb.com/>`_ (an object oriented NoSQL database). These stores
 respectively require the `redis-py <https://redis-py.readthedocs.io>`_ and
-`pymongo <https://api.mongodb.com/python/current/>`_ packages to be installed. 
+`pymongo <https://api.mongodb.com/python/current/>`_ packages to be installed.
 
 For compatibility with the `N5 <https://github.com/saalfeldlab/n5>`_ data format, Zarr also provides
 an N5 backend (this is currently an experimental feature). Similar to the zip storage class, an
@@ -897,6 +897,18 @@ The second invocation here will be much faster. Note that the ``storage_options`
 have become more complex here, to account for the two parts of the supplied
 URL.
 
+It is also possible to initialize the filesytem outside of Zarr and then pass
+it through. This requires creating an :class:`zarr.storage.FSStore` object
+explicitly. For example::
+
+    >>> import s3fs  * doctest: +SKIP
+    >>> fs = s3fs.S3FileSystem(anon=True)  # doctest: +SKIP
+    >>> store = zarr.storage.FSStore('/zarr-demo/store', fs=fs)  # doctest: +SKIP
+    >>> g = zarr.open_group(store)  # doctest: +SKIP
+
+This is useful in cases where you want to also use the same fsspec filesystem object
+separately from Zarr.
+
 .. _fsspec: https://filesystem-spec.readthedocs.io/en/latest/
 
 .. _supported by fsspec: https://filesystem-spec.readthedocs.io/en/latest/api.html#built-in-implementations
@@ -1306,18 +1318,18 @@ filters (e.g., byte-shuffle) have been applied.
 
 Empty chunks
 ~~~~~~~~~~~~
- 
+
 As of version 2.11, it is possible to configure how Zarr handles the storage of
 chunks that are "empty" (i.e., every element in the chunk is equal to the array's fill value).
-When creating an array with ``write_empty_chunks=False``, 
+When creating an array with ``write_empty_chunks=False``,
 Zarr will check whether a chunk is empty before compression and storage. If a chunk is empty,
-then Zarr does not store it, and instead deletes the chunk from storage 
-if the chunk had been previously stored. 
+then Zarr does not store it, and instead deletes the chunk from storage
+if the chunk had been previously stored.
 
-This optimization prevents storing redundant objects and can speed up reads, but the cost is 
-added computation during array writes, since the contents of 
-each chunk must be compared to the fill value, and these advantages are contingent on the content of the array. 
-If you know that your data will form chunks that are almost always non-empty, then there is no advantage to the optimization described above. 
+This optimization prevents storing redundant objects and can speed up reads, but the cost is
+added computation during array writes, since the contents of
+each chunk must be compared to the fill value, and these advantages are contingent on the content of the array.
+If you know that your data will form chunks that are almost always non-empty, then there is no advantage to the optimization described above.
 In this case, creating an array with ``write_empty_chunks=True`` (the default) will instruct Zarr to write every chunk without checking for emptiness.
 
 The following example illustrates the effect of the ``write_empty_chunks`` flag on
@@ -1329,7 +1341,7 @@ the time required to write an array with different values.::
     >>> from tempfile import TemporaryDirectory
     >>> def timed_write(write_empty_chunks):
     ...     """
-    ...     Measure the time required and number of objects created when writing 
+    ...     Measure the time required and number of objects created when writing
     ...     to a Zarr array with random ints or fill value.
     ...     """
     ...     chunks = (8192,)
@@ -1368,8 +1380,8 @@ the time required to write an array with different values.::
             Random Data: 0.1359s, 1024 objects stored
             Empty Data: 0.0301s, 0 objects stored
 
-In this example, writing random data is slightly slower with ``write_empty_chunks=True``, 
-but writing empty data is substantially faster and generates far fewer objects in storage.   
+In this example, writing random data is slightly slower with ``write_empty_chunks=True``,
+but writing empty data is substantially faster and generates far fewer objects in storage.
 
 .. _tutorial_rechunking: