xarray-subset-grid 0.0.1__tar.gz → 0.1.1__tar.gz

{xarray_subset_grid-0.0.1 → xarray_subset_grid-0.1.1}/.gitattributes

@@ -1,3 +1,2 @@
-# GitHub syntax highlighting
-pixi.lock linguist-language=YAML
-
+# GitHub syntax highlighting
+pixi.lock linguist-language=YAML

{xarray_subset_grid-0.0.1 → xarray_subset_grid-0.1.1}/.readthedocs.yaml

@@ -1,13 +1,13 @@
-version: "2"
-
-build:
-  os: "ubuntu-20.04"
-  tools:
-    python: "3.10"
-
-sphinx:
-  configuration: docs/conf.py
-
-python:
-  install:
-    - requirements: docs/requirements.txt
+version: "2"
+
+build:
+  os: "ubuntu-20.04"
+  tools:
+    python: "3.10"
+
+sphinx:
+  configuration: docs/conf.py
+
+python:
+  install:
+    - requirements: docs/requirements.txt

{xarray_subset_grid-0.0.1 → xarray_subset_grid-0.1.1}/CONTRIBUTING.md

@@ -1,129 +1,129 @@
-# Contributors Guide
-
-Interested in improving xarray-subset-grid?
-Have a few minutes to tackle an issue? Or improve the documentation?
-
-## Introduction
-
-First off, thank you for considering contributing to xarray-subset-grid.
-Following these guidelines helps to communicate that you respect the time of the developers managing and developing these open source projects.
-In return, they should reciprocate that respect in addressing your issue,
-assessing changes, and helping you finalize your pull requests.
-So, please take a few minutes to read through this guide.
-
-## What Can I Do?
-
-* Tackle any issues you wish!
-* Contribute code you already have. It does not need to be perfect! We will help you clean
-  things up, test it, etc.
-* Make a tutorial or example of how to do something.
-* Improve documentation of a feature you found troublesome.
-* File a new issue if you run into problems!
-
-## Ground Rules
-
-The goal is to maintain a diverse community that's pleasant for everyone. Please
-be considerate and respectful of others by following our
-[code of conduct](https://github.com/ioos/.github/blob/main/CODE_OF_CONDUCT.md).
-
-* Each pull request should consist of a logical collection of changes.
-  You can include multiple bug fixes in a single pull request,
-  but they should be related.
-  For unrelated changes, please submit multiple pull requests.
-* Do not commit changes to files that are irrelevant to your feature or bug fix
-  (eg: .gitignore).
-* Be willing to accept criticism and work on improving your code; we don't want
-  to break other users' code, so care must be taken not to introduce bugs.
-* Be aware that the pull request review process is not immediate, and is
-  generally proportional to the size of the pull request.
-* PRs with new features, or bugfixes, should not fix existing lints. The more changes in a PR, the harder it will be for the reviewer. We can always send a separate PR with the lint fix later.
-* Avoid making the project "look like your project." We tend to make ourselves at home when writing contributions, but we should avoid renaming things just for renaming sake, moving files around to "organize" the project, or make aesthetic changes without asking the upstream devs first. Such changes, while sometimes desirable, don't bring much value to a PR but do bring extra burden to the reviewers.
-* Do not tackle more than one issue or one feature per PR. While tempting, the smaller the PR, the easier will be to get it merged, reducing merge conflicts, without holding other PRs. Many small ones are always better than a single massive PR.
-* Always state your PR objective clearly in the title "New Feature X", "Bug Fix Y", or "Fixing doc typo".
-* Always add a "longer, but not too long, description of your PR in the body of the first comment.
-* Always write meaningful, short, concise, commit messages. The kind of message your future self will congratulate you.
-* When copying code from other places, like Stack-Overflow (SO), always add the link. That is not only a way to credit the original author of the code, but also add a way to look for the source when debugging. Also, it is not uncommon for a SO answer to be updated with better code.
-* When using AI, also add a comment that you did! And, if possible, add the questions/chat report in a gist and link to it in the PR. While AI can be of great aid, it can also write obfuscated code that is hard to debug if you don't know it was machine generated.
-* Be sure to search the existing issues and PRs before submitting yours. Sometimes these changes are already there and all we need is an extra person on the hill to make the final push. Be that second person and not the one that starts a new hill climb by yourself.
-Always read the development notes when they exist, many questions are already answered there.
-
-## Reporting a bug
-
-The easiest way to get involved is to report issues you encounter when using IOOS Software or by
-requesting something you think is missing.
-
-* Head over to the project issues page.
-* Search to see if your issue already exists or has even been solved previously.
-* If you indeed have a new issue or request, click the "New Issue" button.
-* Fill in as much of the issue template as is relevant. Please be as specific as possible.
-  Include the version of the code you were using, as well as what operating system you
-  are running. If possible, include complete, minimal example code that reproduces the problem.
-
-## Setting up your development environment
-
-We recommend using the [conda](https://conda.io/docs/) or [pixi](https://prefix.dev/) package managers for your Python environments.
-Please take some time to go over the [README](https://github.com/asascience-open/xarray-subset-grid/blob/main/README.md).
-
-Install [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-(link with instructions) on your system if not already available
-(check with ``git --version`` at the command line.)
-
-Login to your [GitHub](https://github.com) account and make a fork of the
-repository by clicking the "Fork" button.
-Clone your fork of the repository (in terminal on Mac/Linux or git shell/GUI on Windows)
-to the location you'd like to keep it.
-We are partial to creating a ``git_repos`` or ``projects`` directory in our home folder.
-
-```sh
-git clone https://github.com/asascience-open/xarray-subset-grid.git
-```
-
-## Pull Requests
-
-The changes to the code source (and documentation)
-should be made via GitHub pull requests against ``main``,
-even for those with administration rights.
-While it's tempting to make changes directly to ``main`` and push them up,
-it is better to make a pull request so that others can give feedback.
-If nothing else,
-this gives a chance for the automated tests to run on the PR.
-This can eliminate "brown paper bag" moments with buggy commits on the main branch.
-
-Push to your fork and submit a pull request.
-
-## What happens after the pull request
-
-You've made your changes, documented them, added some tests, and submitted a pull request.
-What now?
-
-### Code Review
-
-At this point you're waiting on us. You should expect to hear at least a comment within a
-couple of days. We may suggest some changes or improvements or alternatives.
-
-Some things that will increase the chance that your pull request is accepted quickly:
-
-* Write tests.
-* Fix any failed lints shown by pre-commit-ci.
-* Write a [good commit message](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
-
-Pull requests will automatically have tests run by CIs.
-This includes running both the unit tests as well as the code linters.
-The test suite, documentation, style, and more will be checked on various versions of Python with current and legacy packages.
-CIs will run testing on Linux, and Mac, and Windows.
-
-### Merging
-
-Once we're all happy with the pull request, it's time for it to get merged in. Only the
-maintainers can merge pull requests and you should never merge a pull request you have commits
-on as it circumvents the code review. If this is your first or second pull request, we'll
-likely help by rebasing and cleaning up the commit history for you. As your development skills
-increase, we'll help you learn how to do this.
-
-## Further Reading
-
-There are a ton of great resources out there on contributing to open source and on the
-importance of writing tested and maintainable software.
-
-* [How to Contribute to Open Source Guide](https://opensource.guide/how-to-contribute/)
-* [Zen of Scientific Software Maintenance](https://jrleeman.github.io/ScientificSoftwareMaintenance/)
+# Contributors Guide
+
+Interested in improving xarray-subset-grid?
+Have a few minutes to tackle an issue? Or improve the documentation?
+
+## Introduction
+
+First off, thank you for considering contributing to xarray-subset-grid.
+Following these guidelines helps to communicate that you respect the time of the developers managing and developing these open source projects.
+In return, they should reciprocate that respect in addressing your issue,
+assessing changes, and helping you finalize your pull requests.
+So, please take a few minutes to read through this guide.
+
+## What Can I Do?
+
+* Tackle any issues you wish!
+* Contribute code you already have. It does not need to be perfect! We will help you clean
+  things up, test it, etc.
+* Make a tutorial or example of how to do something.
+* Improve documentation of a feature you found troublesome.
+* File a new issue if you run into problems!
+
+## Ground Rules
+
+The goal is to maintain a diverse community that's pleasant for everyone. Please
+be considerate and respectful of others by following our
+[code of conduct](https://github.com/ioos/.github/blob/main/CODE_OF_CONDUCT.md).
+
+* Each pull request should consist of a logical collection of changes.
+  You can include multiple bug fixes in a single pull request,
+  but they should be related.
+  For unrelated changes, please submit multiple pull requests.
+* Do not commit changes to files that are irrelevant to your feature or bug fix
+  (eg: .gitignore).
+* Be willing to accept criticism and work on improving your code; we don't want
+  to break other users' code, so care must be taken not to introduce bugs.
+* Be aware that the pull request review process is not immediate, and is
+  generally proportional to the size of the pull request.
+* PRs with new features, or bugfixes, should not fix existing lints. The more changes in a PR, the harder it will be for the reviewer. We can always send a separate PR with the lint fix later.
+* Avoid making the project "look like your project." We tend to make ourselves at home when writing contributions, but we should avoid renaming things just for renaming sake, moving files around to "organize" the project, or make aesthetic changes without asking the upstream devs first. Such changes, while sometimes desirable, don't bring much value to a PR but do bring extra burden to the reviewers.
+* Do not tackle more than one issue or one feature per PR. While tempting, the smaller the PR, the easier will be to get it merged, reducing merge conflicts, without holding other PRs. Many small ones are always better than a single massive PR.
+* Always state your PR objective clearly in the title "New Feature X", "Bug Fix Y", or "Fixing doc typo".
+* Always add a "longer, but not too long, description of your PR in the body of the first comment.
+* Always write meaningful, short, concise, commit messages. The kind of message your future self will congratulate you.
+* When copying code from other places, like Stack-Overflow (SO), always add the link. That is not only a way to credit the original author of the code, but also add a way to look for the source when debugging. Also, it is not uncommon for a SO answer to be updated with better code.
+* When using AI, also add a comment that you did! And, if possible, add the questions/chat report in a gist and link to it in the PR. While AI can be of great aid, it can also write obfuscated code that is hard to debug if you don't know it was machine generated.
+* Be sure to search the existing issues and PRs before submitting yours. Sometimes these changes are already there and all we need is an extra person on the hill to make the final push. Be that second person and not the one that starts a new hill climb by yourself.
+Always read the development notes when they exist, many questions are already answered there.
+
+## Reporting a bug
+
+The easiest way to get involved is to report issues you encounter when using IOOS Software or by
+requesting something you think is missing.
+
+* Head over to the project issues page.
+* Search to see if your issue already exists or has even been solved previously.
+* If you indeed have a new issue or request, click the "New Issue" button.
+* Fill in as much of the issue template as is relevant. Please be as specific as possible.
+  Include the version of the code you were using, as well as what operating system you
+  are running. If possible, include complete, minimal example code that reproduces the problem.
+
+## Setting up your development environment
+
+We recommend using the [conda](https://conda.io/docs/) or [pixi](https://prefix.dev/) package managers for your Python environments.
+Please take some time to go over the [README](https://github.com/asascience-open/xarray-subset-grid/blob/main/README.md).
+
+Install [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+(link with instructions) on your system if not already available
+(check with ``git --version`` at the command line.)
+
+Login to your [GitHub](https://github.com) account and make a fork of the
+repository by clicking the "Fork" button.
+Clone your fork of the repository (in terminal on Mac/Linux or git shell/GUI on Windows)
+to the location you'd like to keep it.
+We are partial to creating a ``git_repos`` or ``projects`` directory in our home folder.
+
+```sh
+git clone https://github.com/asascience-open/xarray-subset-grid.git
+```
+
+## Pull Requests
+
+The changes to the code source (and documentation)
+should be made via GitHub pull requests against ``main``,
+even for those with administration rights.
+While it's tempting to make changes directly to ``main`` and push them up,
+it is better to make a pull request so that others can give feedback.
+If nothing else,
+this gives a chance for the automated tests to run on the PR.
+This can eliminate "brown paper bag" moments with buggy commits on the main branch.
+
+Push to your fork and submit a pull request.
+
+## What happens after the pull request
+
+You've made your changes, documented them, added some tests, and submitted a pull request.
+What now?
+
+### Code Review
+
+At this point you're waiting on us. You should expect to hear at least a comment within a
+couple of days. We may suggest some changes or improvements or alternatives.
+
+Some things that will increase the chance that your pull request is accepted quickly:
+
+* Write tests.
+* Fix any failed lints shown by pre-commit-ci.
+* Write a [good commit message](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+
+Pull requests will automatically have tests run by CIs.
+This includes running both the unit tests as well as the code linters.
+The test suite, documentation, style, and more will be checked on various versions of Python with current and legacy packages.
+CIs will run testing on Linux, and Mac, and Windows.
+
+### Merging
+
+Once we're all happy with the pull request, it's time for it to get merged in. Only the
+maintainers can merge pull requests and you should never merge a pull request you have commits
+on as it circumvents the code review. If this is your first or second pull request, we'll
+likely help by rebasing and cleaning up the commit history for you. As your development skills
+increase, we'll help you learn how to do this.
+
+## Further Reading
+
+There are a ton of great resources out there on contributing to open source and on the
+importance of writing tested and maintainable software.
+
+* [How to Contribute to Open Source Guide](https://opensource.guide/how-to-contribute/)
+* [Zen of Scientific Software Maintenance](https://jrleeman.github.io/ScientificSoftwareMaintenance/)

{xarray_subset_grid-0.0.1 → xarray_subset_grid-0.1.1}/DevelopmentNotes.txt

@@ -1,17 +1,15 @@
-Development notes:
-
-Various notes you want to know when working on this code.
-
-Data Structures:
-
-Polygons:
-
-Defined as an Nx2 array of (lon, lat) float64
-
-First point is not repeated.
-
-Bounding Box:
-
-A tuple of floats: (min_lon, min_lat, max_lon, max_lat).
-
-
+Development notes:
+
+Various notes you want to know when working on this code.
+
+Data Structures:
+
+Polygons:
+
+Defined as an Nx2 array of (lon, lat) float64
+
+First point is not repeated.
+
+Bounding Box:
+
+A tuple of floats: (min_lon, min_lat, max_lon, max_lat).

{xarray_subset_grid-0.0.1 → xarray_subset_grid-0.1.1}/LICENSE

@@ -1,28 +1,28 @@
-BSD 3-Clause License
-
-Copyright (c) 2024, Applied Science Associates
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-1. Redistributions of source code must retain the above copyright notice, this
-   list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright notice,
-   this list of conditions and the following disclaimer in the documentation
-   and/or other materials provided with the distribution.
-
-3. Neither the name of the copyright holder nor the names of its
-   contributors may be used to endorse or promote products derived from
-   this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+BSD 3-Clause License
+
+Copyright (c) 2024, Applied Science Associates
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

xarray_subset_grid-0.1.1/MANIFEST.in

@@ -0,0 +1,15 @@
+include *.txt
+include README.md
+include pyproject.toml
+
+graft xarray_subset_grid
+
+prune .github
+prune *.egg-info
+prune docs
+prune tests
+
+exclude .gitignore
+exclude .pre-commit-config.yaml
+exclude *.yml
+exclude xarray_subset_grid/_version.py

{xarray_subset_grid-0.0.1 → xarray_subset_grid-0.1.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
-Name: xarray_subset_grid
-Version: 0.0.1
+Name: xarray-subset-grid
+Version: 0.1.1
 Summary: Subset Xarray datasets in time and space
 Author-email: Matthew Iannucci <matt.iannucci@tetratech.com>, "Christopher H. Barker" <chris.barker@noaa.gov>
 License: BSD 3-Clause License
@@ -32,42 +32,42 @@ License: BSD 3-Clause License
         OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
         OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
         
-Project-URL: Homepage, https://github.com/asascience-open/xarray-subset-grid
+Project-URL: Homepage, https://github.com/ioos/xarray-subset-grid/
 Keywords: xarray
 Classifier: Development Status :: 5 - Production/Stable
 Classifier: Intended Audience :: Science/Research
-Classifier: Operating System :: OS Independent
 Classifier: License :: OSI Approved :: BSD License
+Classifier: Operating System :: OS Independent
 Classifier: Programming Language :: Python
-Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
 Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
 Classifier: Topic :: Scientific/Engineering
 Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
-Requires-Dist: numpy
-Requires-Dist: xarray>=2024.6
-Requires-Dist: cf_xarray
+Requires-Dist: cf-xarray
 Requires-Dist: cftime
 Requires-Dist: dask
 Requires-Dist: netcdf4
+Requires-Dist: numpy
+Requires-Dist: xarray>=2024.6
 Provides-Extra: dev
-Requires-Dist: ruff; extra == "dev"
 Requires-Dist: pre-commit; extra == "dev"
-Requires-Dist: pyright; extra == "dev"
 Requires-Dist: pytest; extra == "dev"
 Requires-Dist: pytest-cov; extra == "dev"
+Requires-Dist: ruff; extra == "dev"
 Requires-Dist: sphinx; extra == "dev"
 Requires-Dist: sphinx-rtd-theme; extra == "dev"
 Provides-Extra: examples
 Requires-Dist: fsspec; extra == "examples"
-Requires-Dist: s3fs; extra == "examples"
-Requires-Dist: zarr; extra == "examples"
-Requires-Dist: matplotlib; extra == "examples"
 Requires-Dist: h5netcdf; extra == "examples"
+Requires-Dist: matplotlib; extra == "examples"
+Requires-Dist: s3fs; extra == "examples"
+Requires-Dist: zarr<3; extra == "examples"
 Dynamic: license-file
 
 # xarray-subset-grid
@@ -78,36 +78,42 @@ Subset Xarray datasets in space while retaining the original grid for complex gr
 
 ### `pip compatible`
 
-This package is not yet released on pypi, for now install using git:
+This package is available on pypi:
 
 ```
-pip install xarray_subset_grid@git+https://github.com/asascience-open/xarray-subset-grid.git
+python -m pip install xarray-subset-grid
 ```
 
-Or clone the project from git and build / install it from there.
+And also on conda-forge:
+
+```
+conda install -c conda-forge xarray-subset-grid
+```
 
 ## Usage
 
-This package is designed to be used in conjuction with [`xarray`](https://xarray.dev/). Given a [CF Compliant](https://cfconventions.org/) `xarray` dataset named `ds`, this package can be accessed using the `xsg` accessor:
+This package is designed to be used in conjunction with [`xarray`](https://xarray.dev/). Given a [CF Compliant](https://cfconventions.org/) `xarray` dataset named `ds`, this package can be accessed using the `xsg` accessor:
 
 ```python
 # Get the interprested grid class
 grid = ds.xsg
 
 # subset to only include temperature
-ds_temp = ds.xsg.subset_vars(['temp'])
+ds_temp = ds.xsg.subset_vars(["temp"])
 
 # subset by bounding box
 ds_subset_bbox = ds.xsg.subset_bbox([-72, 32, -70, 35])
 
 # or by polygon
-poly = np.array([
-    [-72, 32],
-    [-72, 33], 
-    [-73, 33], 
-    [-73, 31], 
-    [-72, 32],
-])
+poly = np.array(
+    [
+        [-72, 32],
+        [-72, 33],
+        [-73, 33],
+        [-73, 31],
+        [-72, 32],
+    ]
+)
 ds_subset_poly = ds.xsg.subset_polygon(poly)
 ```
 
@@ -130,7 +136,7 @@ Then install the project in local edit mode:
 pip install -e .
 ```
 
-Once installed, the tests can be run: 
+Once installed, the tests can be run:
 
 ```bash
 python -m pytest
@@ -151,10 +157,11 @@ There are three "environments" set up for pixi:
 - `dev`
 - `examples`
 
-And two "tasks": 
+And three "tasks":
 
 - `lint`
-- `test`
+- `test` : run most of the tests
+- `test_all` : run the tests that access AWS -- i.e. download data directly.
 
 To run the tests in an isolated environment:
 
@@ -162,25 +169,26 @@ To run the tests in an isolated environment:
 pixi run -e dev test
 ```
 
-To run a shell to do dev work:
-
+Or with a specific python version:
 ```bash
-pixi shell -e dev
+pixi run -e test312 test
 ```
 
-If you want to run the examples (notebooks and al that):
+Options are: `test310` `test311` `test312` `test313`
+
+
+To run a shell to do dev work:
 
 ```bash
-pixi shell -e all
+pixi shell -e dev
 ```
 
-That will set up a conda environment with all the develop dependencies.
-
-To run a shell in which you can run the examples:
+To run a shell in which you can run the examples (notebooks and al that):
 
 ```bash
 pixi shell -e examples
 ```
+
 To run a shell with everything (dev and example deps:
 
 ```bash