Prune stores

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere

[d-v-b]

Removes a lot of stores from the v2 codebase. I basically removed every store that required an extra dependency (other than fsspec), and also removed the N5 stores and the sqlite store. The logic for doing this is to thin down the v2 codebase.

Depends on #1742.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

This PR specifically removes following the following v2 stores, and their v3 counterparts:

• ABSStore
• DBMStore,
• LMDBStore
• MongoDBStore
• RedisStore
• SQLiteStore
• ZipStore

One question that @jhamman raised was whether we want to remove ZipStore or not. Since FSSpec supports Zip archives as a backend, is it possible that we could get ZipStore functionality via FSStore? @martindurant what do you think?

Once we decide on whether or not we keep ZipStore, then I think this PR is good to go, barring any other feedback / concerns.

[rabernat]

My feeling is that Zip stores are really an underappreciated feature of Zarr. Whatever we choose in terms of design, we should document Zip stores prominently.

I'm curious--are there performance or feature differences between the native Zip store and the fsspec version?

[martindurant]

fsspec's ZipFS ought to be able to do everything, I would have thought, with the additional plus of being able to work with remote zips too (usually "r" and "w" modes only). It has certainly not been tested for speed, convenience being the priority over performance. A more specialised, and therefore simple, implementation can be reasonable if there is someone to maintain it.

@mxmlnkn , you might be interested by another way of thinking of compressed bunch-of-files containers discussed here.

[d-v-b]

Updates:

• My initial effort in this PR removed everything in one commit. I have reverted that, and broken the removals into one commit per storage class.
• I am keeping ZipStore, since it doesn't require any external dependencies and some community members expressed an interested in keeping it.

I think the ZipStore was the only controversial aspect here, and that issue should be sorted. I would like to merge this in the next few days, unless anyone has objections.

[dstansby]

Is this still something we want to get into zarr v3? And if so, would it be better to deprecate everything for a few releases and then remove it first? If not, and it's just going to be removed without warning, there should be a clear guide to how users can adapt their code if they were using these stores.

[jhamman]

closing as we have done this elsewhere