sl-shared-assets 2.0.1__tar.gz → 3.0.0__tar.gz

{sl_shared_assets-2.0.1 → sl_shared_assets-3.0.0}/PKG-INFO

@@ -1,7 +1,7 @@
 Metadata-Version: 2.4
 Name: sl-shared-assets
-Version: 2.0.1
-Summary: Stores assets shared between multiple Sun (NeuroAI) lab data pipelines.
+Version: 3.0.0
+Summary: Provides data acquisition and processing assets shared between Sun (NeuroAI) lab libraries.
 Project-URL: Homepage, https://github.com/Sun-Lab-NBB/sl-shared-assets
 Project-URL: Documentation, https://sl-shared-assets-api-docs.netlify.app/
 Author: Ivan Kondratyev, Kushaan Gupta, Natalie Yeung
@@ -681,7 +681,7 @@ License:                     GNU GENERAL PUBLIC LICENSE
         Public License instead of this License.  But first, please read
         <https://www.gnu.org/licenses/why-not-lgpl.html>.
 License-File: LICENSE
-Keywords: acquisition,assets,data,processing,sunlab
+Keywords: acquisition,assets,data,processing,server,sunlab
 Classifier: Development Status :: 5 - Production/Stable
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)
@@ -691,13 +691,13 @@ Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.11
 Requires-Dist: appdirs==1.4.4
-Requires-Dist: ataraxis-base-utilities==3.0.1
+Requires-Dist: ataraxis-base-utilities==3.1.0
 Requires-Dist: ataraxis-data-structures==3.1.1
 Requires-Dist: ataraxis-time==3.0.0
 Requires-Dist: click==8.2.1
 Requires-Dist: filelock==3.18.0
 Requires-Dist: natsort==8.4.0
-Requires-Dist: numpy<2.3.0,>=2.0.2
+Requires-Dist: numpy==2.2.6
 Requires-Dist: paramiko==3.5.1
 Requires-Dist: polars==1.31.0
 Requires-Dist: pyarrow==20.0.0
@@ -706,7 +706,6 @@ Requires-Dist: simple-slurm==0.3.6
 Requires-Dist: tqdm==4.67.1
 Requires-Dist: xxhash==3.5.0
 Provides-Extra: conda
-Requires-Dist: grayskull<3,>=2; extra == 'conda'
 Requires-Dist: hatchling<2,>=1; extra == 'conda'
 Requires-Dist: importlib-metadata<9,>=8; extra == 'conda'
 Requires-Dist: mypy<2,>=1; extra == 'conda'
@@ -725,7 +724,7 @@ Requires-Dist: appdirs==1.4.4; extra == 'condarun'
 Requires-Dist: click==8.2.1; extra == 'condarun'
 Requires-Dist: filelock==3.18.0; extra == 'condarun'
 Requires-Dist: natsort==8.4.0; extra == 'condarun'
-Requires-Dist: numpy<2.3.0,>=2.0.2; extra == 'condarun'
+Requires-Dist: numpy==2.2.6; extra == 'condarun'
 Requires-Dist: paramiko==3.5.1; extra == 'condarun'
 Requires-Dist: polars==1.31.0; extra == 'condarun'
 Requires-Dist: pyarrow==20.0.0; extra == 'condarun'
@@ -734,7 +733,6 @@ Requires-Dist: tqdm==4.67.1; extra == 'condarun'
 Provides-Extra: dev
 Requires-Dist: ataraxis-automation<6,>=5; extra == 'dev'
 Requires-Dist: build<2,>=1; extra == 'dev'
-Requires-Dist: grayskull<3,>=2; extra == 'dev'
 Requires-Dist: hatchling<2,>=1; extra == 'dev'
 Requires-Dist: importlib-metadata<9,>=8; extra == 'dev'
 Requires-Dist: mypy<2,>=1; extra == 'dev'
@@ -774,6 +772,7 @@ A Python library that stores assets shared between multiple Sun (NeuroAI) lab da
 ![PyPI - License](https://img.shields.io/pypi/l/sl-shared-assets)
 ![PyPI - Status](https://img.shields.io/pypi/status/sl-shared-assets)
 ![PyPI - Wheel](https://img.shields.io/pypi/wheel/sl-shared-assets)
+
 ___
 
 ## Detailed Description
@@ -815,7 +814,7 @@ All software library dependencies are installed automatically as part of library
 
 Note, installation from source is ***highly discouraged*** for everyone who is not an active project developer.
 
-1. Download this repository to your local machine using your preferred method, such as Git-cloning. Use one
+1. Download this repository to your local machine using any method, such as Git-cloning. Use one
    of the stable releases from [GitHub](https://github.com/Sun-Lab-NBB/sl-shared-assets/releases).
 2. Unpack the downloaded zip and note the path to the binary wheel (`.whl`) file contained in the archive.
 3. Run ```python -m pip install WHEEL_PATH```, replacing 'WHEEL_PATH' with the path to the wheel file, to install the 
@@ -828,12 +827,128 @@ Use the following command to install the library using pip: ```pip install sl-sh
 
 ## Usage
 
-All library components are intended to be used via other Sun lab libraries. Developers should study the API and CLI 
+Most library components are intended to be used via other Sun lab libraries. Developers should study the API and CLI 
 documentation below to learn how to use library components in other Sun lab libraries. For notes on using shared 
 assets for data acquisition, see the [sl-experiment](https://github.com/Sun-Lab-NBB/sl-experiment) library ReadMe.
 For notes on using shared assets for data processing, see the [sl-forgery](https://github.com/Sun-Lab-NBB/sl-forgery) 
 library ReadMe.
 
+The only exception to the note above is the **server.py** package exposed by this library. This package exposes an API 
+for running headless and a CLI for running interactive Simple Linux Utility for Resource Management (SLURM)-managed 
+jobs on remote compute clusters.
+
+### Generating Access Credentials
+
+To access any remote server, the user is required to first generate the access credentials. The credentials are stored 
+inside the 'server_credentials.yaml' file, which is generated by using the `sl-create-server-credentials` command.
+**Note!** Users are advised to generate this file in a secure (non-shared) location on their local machine.
+
+### Running Headless Jobs
+
+A headless job is a job that does not require any user interaction during runtime. Currently, all headless jobs in the 
+lab rely on pip-installable packages that expose a callable Command-Line Interface to carry out some type of
+data processing. In this regard, **running a headless job is equivalent to calling a CLI command on your local 
+machine**, except that the command is executed on a remote compute server. Therefore, the primary purpose of the API 
+exposed by this library is to transfer the target command request to the remote server, execute it, and monitor the 
+runtime status until it is complete.
+
+For example, the [sl-suite2p package](https://github.com/Sun-Lab-NBB/suite2p) maintained in the lab exposes a CLI to 
+process 2-Photon data from experiment sessions. During data processing by the 
+[sl-forgery](https://github.com/Sun-Lab-NBB/sl-forgery) library, a remote job is sent to the server that uses the CLI 
+exposed by the sl-suite2p package to process target session(s).
+
+### Creating Jobs
+All remote jobs are sent to the server in the form of an executable *shell* (.sh) script. The script is composed on the 
+local machine that uses this library and transferred to a temporary server directory using Secure Shell File 
+Transfer Protocol (SFTP). The server is then instructed to evaluate (run) the script using SLURM job manager, via a 
+Secure Shell (SSH) session.
+
+Broadly, each job consists of three major steps, which correspond to three major sections of the job shell script:
+1. **Setting up the job environment**. Each job script starts with a SLURM job parameter block, which tells SLURM 
+   what resources (CPUs, GPUs, RAM, etc.) the job requires. When resources become available, SLURM generates a virtual
+   environment and runs the rest of the job script in that environment. This forms the basis for using the shared
+   compute resources fairly, as SLURM balances resource allocation and the order of job execution for all users.
+2. **Activating the target conda environment**. Currently, all jobs are assumed to use Python libraries to execute the 
+   intended data processing. Similar to processing data locally, each job expects the remote server to provide a 
+   Conda environment preconfigured with necessary assets (packages) to run the job. Therefore, each job contains a 
+   section that activates the user-defined conda environment before running the rest of the job.
+3. **Executing processing**. The final section is typically unique to each job and calls specific CLI commands or runs 
+   specific Python modules. Since each job is submitted as a shell script, it can do anything a server shell can
+   do. Therefore, despite python-centric approach to data processing in the lab, a remote job composed via this library 
+   can execute ***any*** arbitrary command available to the user on the remove server.
+
+Use the *Job* class exposed by this library to compose remote jobs. **Steps 1 and 2** of each job are configured when 
+initializing the Job instance, while **step 3** is added via the `add_command()` method of the Job class:
+```
+# First, import the job class
+from pathlib import Path
+from sl_shared_assets import Job
+
+# Next, instantiate a new Job object. For example, this job is used to verify the integrity of raw experiment data as
+# it is transferred to the long-term storage destination (server) by the sl-experiment library.
+job = Job(
+    job_name="data_integrity_verification",
+    output_log=Path("/temp/output.txt"),
+    error_log=Path("/temp/errors.txt"),
+    working_directory=Path("/temp/test_job"),
+    conda_environment="test_environment",
+    cpus_to_use=20,
+    ram_gb=50,
+    time_limit=20,
+)
+
+# Finally, add a CLI command call (the actual work to be done by the job). Here, the job calls the
+# 'sl-verify-session' command exposed by the sl-shared-assets library installed in the target environment on the server.
+# Use this method to add commands as you would type them in your local terminal / shell / command line.
+job.add_command(f"sl-verify-session -sp /temp/test_session")
+```
+
+### Submitting and Monitoring Jobs:
+To submit the job to the remote server, use a **Server** class instance. This class encapsulates access to the target 
+remote compute server and uses the server_credentials.yaml file to determine server access credentials (see above):
+```
+# Initialize the Server class using precreated server credentials file
+server = Server(credentials_path=Path("/temp/server_credentials.yaml"))
+
+# Submit the job (generated in the previous code snippet) to the server
+job = server.submit_job(job)
+
+# Wait for the server to complete the job
+delay_timer = PrecisionTimer("s")
+while not server.job_complete(job=job):
+    delay_timer.delay_noblock(delay=5, allow_sleep=True)
+```
+
+**Note!** The Server class only checks whether the job is running on the server, but not the outcome of the job. For 
+that, you can either manually check the output and error logs for the job or come up with a programmatic way of 
+checking the outcome. All developers are highly advised to study the API documentation for the Job and Server classes 
+to use them most effectively.
+
+**Critical!** Since running remote jobs is largely equivalent to executing them locally, all users are highly encouraged
+to test their job scripts locally before deploying them server-side. If a script works on a local machine, it is likely 
+that the script would behave similarly and work on the server.
+
+### Interactive Jobs
+
+Interactive jobs are a special extension of the headless job type discussed above. Specifically, an interactive job is 
+a headless job, whose only purpose is to **create and maintain a Jupyter lab server** under the SLURM control. 
+Specifically, it requests SLURM to set up an isolated environment, starts a Jupyter server in that environment, and 
+sends the credentials for the started server back to the user.
+
+In essence, this allocates a set of resources the user can use interactively by running various Jupyter notebooks. 
+While convenient for certain data analysis cases, this type of jobs has the potential to inefficiently hog server 
+resources for prolonged periods of time. Therefore, users are encouraged to only resort to this type of jobs when 
+strictly necessary and to minimize the resources and time allocated to running these jobs.
+
+To run an interactive job, call the `sl-start-jupyter` CLI command exposed by this library and follow the instructions 
+printed to the terminal by the command during runtime.
+
+**Critical!** While this command tries to minimize collisions with other users, it is possible that an access port 
+collision occurs when multiple users try to instantiate a jupyter server at the same time. If you cannot authenticate
+with the Jupyter server, this likely indicates that the target port was in use and Jupyter automatically incremented the
+port number by 1. In this case, add 1 to your port number and try connecting to that port using the Jupyter credentials 
+provided by the command. For example, if your target port was '8888,' try port '8889.'
+
 ---
 
 ## API Documentation
@@ -849,7 +964,7 @@ ___
 
 ## Versioning
 
-We use [semantic versioning](https://semver.org/) for this project. For the versions available, see the 
+This project uses [semantic versioning](https://semver.org/). For the versions available, see the 
 [tags on this repository](https://github.com/Sun-Lab-NBB/sl-shared-assets/tags).
 
 ---
@@ -858,7 +973,6 @@ We use [semantic versioning](https://semver.org/) for this project. For the vers
 
 - Ivan Kondratyev ([Inkaros](https://github.com/Inkaros))
 - Kushaan Gupta ([kushaangupta](https://github.com/kushaangupta))
-- Yuantao Deng ([YuantaoDeng](https://github.com/YuantaoDeng))
 - Natalie Yeung
 
 ___
@@ -873,7 +987,7 @@ ___
 
 - All Sun lab [members](https://neuroai.github.io/sunlab/people) for providing the inspiration and comments during the
   development of this library.
-- The creators of all other projects used in our development automation pipelines and source code 
+- The creators of all other projects used in the development automation pipelines and source code of this project
   [see pyproject.toml](pyproject.toml).
 
 ---

sl_shared_assets-3.0.0/README.md

@@ -0,0 +1,230 @@
+# sl-shared-assets
+A Python library that stores assets shared between multiple Sun (NeuroAI) lab data pipelines.
+
+![PyPI - Version](https://img.shields.io/pypi/v/sl-shared-assets)
+![PyPI - Python Version](https://img.shields.io/pypi/pyversions/sl-shared-assets)
+[![uv](https://tinyurl.com/uvbadge)](https://github.com/astral-sh/uv)
+[![Ruff](https://tinyurl.com/ruffbadge)](https://github.com/astral-sh/ruff)
+![type-checked: mypy](https://img.shields.io/badge/type--checked-mypy-blue?style=flat-square&logo=python)
+![PyPI - License](https://img.shields.io/pypi/l/sl-shared-assets)
+![PyPI - Status](https://img.shields.io/pypi/status/sl-shared-assets)
+![PyPI - Wheel](https://img.shields.io/pypi/wheel/sl-shared-assets)
+
+___
+
+## Detailed Description
+
+Primarily, this library is designed to make the two main Sun lab libraries used for data acquisition 
+([sl-experiment](https://github.com/Sun-Lab-NBB/sl-experiment)) and processing 
+([sl-forgery](https://github.com/Sun-Lab-NBB/sl-forgery)) independent of each other. This is beneficial, as both 
+libraries feature an extensive and largely incompatible set of runtime dependencies. Moreover, having a shared
+repository of classes and tools reused across Sun lab pipelines streamlines the maintenance of these tools.
+
+The library broadly stores two types of assets. First, it stores various dataclasses used to save the data acquired 
+during experiments in the lab and the dataclasses used to configure data acquisition and processing runtimes. Secondly, 
+it stores the tools used to safely move the data between the machines (computers) used in the data acquisition and 
+processing, and provides the API for running various data processing jobs on remote compute servers.
+
+---
+
+## Table of Contents
+
+- [Dependencies](#dependencies)
+- [Installation](#installation)
+- [Usage](#usage)
+- [API Documentation](#api-documentation)
+- [Versioning](#versioning)
+- [Authors](#authors)
+- [License](#license)
+- [Acknowledgements](#Acknowledgments)
+___
+
+## Dependencies
+
+All software library dependencies are installed automatically as part of library installation.
+
+---
+
+## Installation
+
+### Source
+
+Note, installation from source is ***highly discouraged*** for everyone who is not an active project developer.
+
+1. Download this repository to your local machine using any method, such as Git-cloning. Use one
+   of the stable releases from [GitHub](https://github.com/Sun-Lab-NBB/sl-shared-assets/releases).
+2. Unpack the downloaded zip and note the path to the binary wheel (`.whl`) file contained in the archive.
+3. Run ```python -m pip install WHEEL_PATH```, replacing 'WHEEL_PATH' with the path to the wheel file, to install the 
+   wheel into the active python environment.
+
+### pip
+Use the following command to install the library using pip: ```pip install sl-shared-assets```.
+
+---
+
+## Usage
+
+Most library components are intended to be used via other Sun lab libraries. Developers should study the API and CLI 
+documentation below to learn how to use library components in other Sun lab libraries. For notes on using shared 
+assets for data acquisition, see the [sl-experiment](https://github.com/Sun-Lab-NBB/sl-experiment) library ReadMe.
+For notes on using shared assets for data processing, see the [sl-forgery](https://github.com/Sun-Lab-NBB/sl-forgery) 
+library ReadMe.
+
+The only exception to the note above is the **server.py** package exposed by this library. This package exposes an API 
+for running headless and a CLI for running interactive Simple Linux Utility for Resource Management (SLURM)-managed 
+jobs on remote compute clusters.
+
+### Generating Access Credentials
+
+To access any remote server, the user is required to first generate the access credentials. The credentials are stored 
+inside the 'server_credentials.yaml' file, which is generated by using the `sl-create-server-credentials` command.
+**Note!** Users are advised to generate this file in a secure (non-shared) location on their local machine.
+
+### Running Headless Jobs
+
+A headless job is a job that does not require any user interaction during runtime. Currently, all headless jobs in the 
+lab rely on pip-installable packages that expose a callable Command-Line Interface to carry out some type of
+data processing. In this regard, **running a headless job is equivalent to calling a CLI command on your local 
+machine**, except that the command is executed on a remote compute server. Therefore, the primary purpose of the API 
+exposed by this library is to transfer the target command request to the remote server, execute it, and monitor the 
+runtime status until it is complete.
+
+For example, the [sl-suite2p package](https://github.com/Sun-Lab-NBB/suite2p) maintained in the lab exposes a CLI to 
+process 2-Photon data from experiment sessions. During data processing by the 
+[sl-forgery](https://github.com/Sun-Lab-NBB/sl-forgery) library, a remote job is sent to the server that uses the CLI 
+exposed by the sl-suite2p package to process target session(s).
+
+### Creating Jobs
+All remote jobs are sent to the server in the form of an executable *shell* (.sh) script. The script is composed on the 
+local machine that uses this library and transferred to a temporary server directory using Secure Shell File 
+Transfer Protocol (SFTP). The server is then instructed to evaluate (run) the script using SLURM job manager, via a 
+Secure Shell (SSH) session.
+
+Broadly, each job consists of three major steps, which correspond to three major sections of the job shell script:
+1. **Setting up the job environment**. Each job script starts with a SLURM job parameter block, which tells SLURM 
+   what resources (CPUs, GPUs, RAM, etc.) the job requires. When resources become available, SLURM generates a virtual
+   environment and runs the rest of the job script in that environment. This forms the basis for using the shared
+   compute resources fairly, as SLURM balances resource allocation and the order of job execution for all users.
+2. **Activating the target conda environment**. Currently, all jobs are assumed to use Python libraries to execute the 
+   intended data processing. Similar to processing data locally, each job expects the remote server to provide a 
+   Conda environment preconfigured with necessary assets (packages) to run the job. Therefore, each job contains a 
+   section that activates the user-defined conda environment before running the rest of the job.
+3. **Executing processing**. The final section is typically unique to each job and calls specific CLI commands or runs 
+   specific Python modules. Since each job is submitted as a shell script, it can do anything a server shell can
+   do. Therefore, despite python-centric approach to data processing in the lab, a remote job composed via this library 
+   can execute ***any*** arbitrary command available to the user on the remove server.
+
+Use the *Job* class exposed by this library to compose remote jobs. **Steps 1 and 2** of each job are configured when 
+initializing the Job instance, while **step 3** is added via the `add_command()` method of the Job class:
+```
+# First, import the job class
+from pathlib import Path
+from sl_shared_assets import Job
+
+# Next, instantiate a new Job object. For example, this job is used to verify the integrity of raw experiment data as
+# it is transferred to the long-term storage destination (server) by the sl-experiment library.
+job = Job(
+    job_name="data_integrity_verification",
+    output_log=Path("/temp/output.txt"),
+    error_log=Path("/temp/errors.txt"),
+    working_directory=Path("/temp/test_job"),
+    conda_environment="test_environment",
+    cpus_to_use=20,
+    ram_gb=50,
+    time_limit=20,
+)
+
+# Finally, add a CLI command call (the actual work to be done by the job). Here, the job calls the
+# 'sl-verify-session' command exposed by the sl-shared-assets library installed in the target environment on the server.
+# Use this method to add commands as you would type them in your local terminal / shell / command line.
+job.add_command(f"sl-verify-session -sp /temp/test_session")
+```
+
+### Submitting and Monitoring Jobs:
+To submit the job to the remote server, use a **Server** class instance. This class encapsulates access to the target 
+remote compute server and uses the server_credentials.yaml file to determine server access credentials (see above):
+```
+# Initialize the Server class using precreated server credentials file
+server = Server(credentials_path=Path("/temp/server_credentials.yaml"))
+
+# Submit the job (generated in the previous code snippet) to the server
+job = server.submit_job(job)
+
+# Wait for the server to complete the job
+delay_timer = PrecisionTimer("s")
+while not server.job_complete(job=job):
+    delay_timer.delay_noblock(delay=5, allow_sleep=True)
+```
+
+**Note!** The Server class only checks whether the job is running on the server, but not the outcome of the job. For 
+that, you can either manually check the output and error logs for the job or come up with a programmatic way of 
+checking the outcome. All developers are highly advised to study the API documentation for the Job and Server classes 
+to use them most effectively.
+
+**Critical!** Since running remote jobs is largely equivalent to executing them locally, all users are highly encouraged
+to test their job scripts locally before deploying them server-side. If a script works on a local machine, it is likely 
+that the script would behave similarly and work on the server.
+
+### Interactive Jobs
+
+Interactive jobs are a special extension of the headless job type discussed above. Specifically, an interactive job is 
+a headless job, whose only purpose is to **create and maintain a Jupyter lab server** under the SLURM control. 
+Specifically, it requests SLURM to set up an isolated environment, starts a Jupyter server in that environment, and 
+sends the credentials for the started server back to the user.
+
+In essence, this allocates a set of resources the user can use interactively by running various Jupyter notebooks. 
+While convenient for certain data analysis cases, this type of jobs has the potential to inefficiently hog server 
+resources for prolonged periods of time. Therefore, users are encouraged to only resort to this type of jobs when 
+strictly necessary and to minimize the resources and time allocated to running these jobs.
+
+To run an interactive job, call the `sl-start-jupyter` CLI command exposed by this library and follow the instructions 
+printed to the terminal by the command during runtime.
+
+**Critical!** While this command tries to minimize collisions with other users, it is possible that an access port 
+collision occurs when multiple users try to instantiate a jupyter server at the same time. If you cannot authenticate
+with the Jupyter server, this likely indicates that the target port was in use and Jupyter automatically incremented the
+port number by 1. In this case, add 1 to your port number and try connecting to that port using the Jupyter credentials 
+provided by the command. For example, if your target port was '8888,' try port '8889.'
+
+---
+
+## API Documentation
+
+See the [API documentation](https://sl-shared-assets-api-docs.netlify.app/) for the
+detailed description of the methods and classes exposed by components of this library.
+
+**Note!** The API documentation includes important information about Command-Line-Interfaces (CLIs) exposed by this 
+library as part of installation into a Python environment. All users are highly encouraged to study the CLI 
+documentation to learn how to use library components via the terminal.
+
+___
+
+## Versioning
+
+This project uses [semantic versioning](https://semver.org/). For the versions available, see the 
+[tags on this repository](https://github.com/Sun-Lab-NBB/sl-shared-assets/tags).
+
+---
+
+## Authors
+
+- Ivan Kondratyev ([Inkaros](https://github.com/Inkaros))
+- Kushaan Gupta ([kushaangupta](https://github.com/kushaangupta))
+- Natalie Yeung
+
+___
+
+## License
+
+This project is licensed under the GPL3 License: see the [LICENSE](LICENSE) file for details.
+
+___
+
+## Acknowledgments
+
+- All Sun lab [members](https://neuroai.github.io/sunlab/people) for providing the inspiration and comments during the
+  development of this library.
+- The creators of all other projects used in the development automation pipelines and source code of this project
+  [see pyproject.toml](pyproject.toml).
+
+---

{sl_shared_assets-2.0.1 → sl_shared_assets-3.0.0}/docs/source/api.rst

@@ -25,6 +25,14 @@ Command Line Interfaces
    :prog: sl-ascend-tyche
    :nested: full
 
+.. click:: sl_shared_assets.cli:start_jupyter_server
+   :prog: sl-start-jupyter
+   :nested: full
+
+.. click:: sl_shared_assets.cli:resolve_dataset_marker
+   :prog: sl-dataset-marker
+   :nested: full
+
 Tools
 =====
 .. automodule:: sl_shared_assets.tools

{sl_shared_assets-2.0.1 → sl_shared_assets-3.0.0}/docs/source/conf.py

@@ -5,7 +5,7 @@ import importlib_metadata
 project = 'sl-shared-assets'
 # noinspection PyShadowingBuiltins
 copyright = '2025, Sun (NeuroAI) lab'
-authors = ['Ivan Kondratyev', 'Kushaan Gupta', 'Yuantao Deng', 'Natalie Yeung']
+authors = ['Ivan Kondratyev', 'Kushaan Gupta', 'Natalie Yeung']
 # Extracts the project version from the .toml file.
 release = importlib_metadata.version("sl-shared-assets")
 

{sl_shared_assets-2.0.1 → sl_shared_assets-3.0.0}/docs/source/welcome.rst

@@ -1,10 +1,11 @@
 Welcome to sl-shared-assets API documentation page
 ==================================================
 
-sl-shared-assets is a Python library that stores assets shared between multiple Sun (NeuroAI) lab data pipelines.
+sl-shared-assets is a Python library that provides data acquisition and processing assets shared between Sun (NeuroAI)
+lab libraries.
 
 This library is developed in the `Sun lab <https://neuroai.github.io/sunlab/>`_ at Cornell University. The main purpose
-of this library is to provide the tools adn assets used by multiple other data acquisition and processing libraries in
+of this library is to provide the tools and assets used by multiple other data acquisition and processing libraries in
 the lab to avoid cross-dependency issues.
 
 This website only contains the API documentation for the classes and methods offered by this library. See the project