toolfuncs 0.1.0__tar.gz

toolfuncs-0.1.0/.github/workflows/release.yml

@@ -0,0 +1,73 @@
+name: Publish release
+
+on:
+  release:
+    types: [published]
+
+jobs:
+  build:
+    name: Build distributions
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+
+    steps:
+      - name: Check out the release tag
+        uses: actions/checkout@v6
+        with:
+          persist-credentials: false
+
+      - name: Set up Python
+        uses: actions/setup-python@v6
+        with:
+          python-version: "3.x"
+
+      - name: Verify that the tag matches the package version
+        env:
+          RELEASE_TAG: ${{ github.event.release.tag_name }}
+        run: |
+          python - <<'PY'
+          import os
+          import pathlib
+          import tomllib
+
+          version = tomllib.loads(pathlib.Path("pyproject.toml").read_text())["project"]["version"]
+          expected_tag = f"v{version}"
+          if os.environ["RELEASE_TAG"] != expected_tag:
+              raise SystemExit(
+                  f"release tag {os.environ['RELEASE_TAG']!r} does not match {expected_tag!r}"
+              )
+          PY
+
+      - name: Install the build frontend
+        run: python -m pip install --disable-pip-version-check build
+
+      - name: Build the wheel and source distribution
+        run: python -m build
+
+      - name: Store the distributions
+        uses: actions/upload-artifact@v5
+        with:
+          name: python-package-distributions
+          path: dist/
+          if-no-files-found: error
+
+  publish:
+    name: Publish to PyPI
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/toolfuncs/
+    permissions:
+      id-token: write
+
+    steps:
+      - name: Download the distributions
+        uses: actions/download-artifact@v6
+        with:
+          name: python-package-distributions
+          path: dist/
+
+      - name: Publish the distributions
+        uses: pypa/gh-action-pypi-publish@release/v1

toolfuncs-0.1.0/.gitignore

@@ -0,0 +1,9 @@
+__pycache__/
+*.py[cod]
+.coverage
+.pytest_cache/
+.ruff_cache/
+.basedpyright/
+build/
+dist/
+*.egg-info/

toolfuncs-0.1.0/.python-version

@@ -0,0 +1 @@
+3.11

toolfuncs-0.1.0/PKG-INFO

@@ -0,0 +1,209 @@
+Metadata-Version: 2.5
+Name: toolfuncs
+Version: 0.1.0
+Summary: Function-first Python tools with matching import and command-line interfaces
+Project-URL: Repository, https://github.com/nimashoghi/toolfuncs
+Project-URL: Issues, https://github.com/nimashoghi/toolfuncs/issues
+Author-email: Nima Shoghi <nima@boltz.bio>
+Requires-Python: >=3.11
+Requires-Dist: cyclopts<5,>=4.23.2
+Requires-Dist: fsspec[github,http]>=2025.3.0
+Requires-Dist: packaging>=24
+Requires-Dist: pip>=25
+Requires-Dist: pydantic-core<3,>=2.20
+Description-Content-Type: text/markdown
+
+# toolfuncs
+
+`toolfuncs` is a small function-calling convention for Python tools. A tool is a Python module whose typed public functions are its interface. The same functions can be called directly from Python or projected into a command-line interface without maintaining a second wrapper API.
+
+Discoverable tools live in a project or user-wide tool directory in one of two forms: a PEP 723 Python file or one packaged `src` project layout. The separate `import_path()` utility can load broader Python sources from local paths and fsspec URLs.
+
+## The basic model
+
+Write ordinary typed functions and register the CLI-callable operations on `toolfuncs.App`:
+
+```python
+#!/usr/bin/env -S uv run --script
+# /// script
+# requires-python = ">=3.11"
+# dependencies = ["toolfuncs"]
+# [tool.toolfuncs]
+# description = "Render values for another program."
+# ///
+
+from pathlib import Path
+
+from toolfuncs import App
+
+app = App()
+
+
+@app.command
+def render(value: str, *, output: Path | None = None) -> dict[str, object]:
+    """Return a value and its optional output path."""
+
+    return {"value": value, "output": output}
+
+
+if __name__ == "__main__":
+    app()
+```
+
+The Python interface is the definition:
+
+```python
+from pathlib import Path
+
+from toolfuncs import renderer
+
+result = renderer.render("hello", output=Path("result.txt"))
+```
+
+The CLI is derived from that same signature and returns strict JSON:
+
+```console
+$ toolfuncs renderer render hello --output result.txt
+{"value": "hello", "output": "result.txt"}
+```
+
+`toolfuncs` directly depends on Cyclopts and `pydantic-core`. Its `App` is a Cyclopts app with the established strict-JSON result action as its default, so a tool imports only `toolfuncs` rather than importing and configuring those libraries itself. `Parameter`, `Token`, `Group`, `validators`, `types`, and `to_jsonable_python` are also re-exported for tools that need the corresponding advanced behavior. Passing `result_action=` explicitly preserves Cyclopts' ordinary override behavior for streaming or domain-specific status policies.
+
+The decorator registers the original function without wrapping it. Direct Python calls therefore receive the original object and exceptions. CLI calls parse annotated values, emit one JSON value on stdout, and fail nonzero when parsing, execution, or serialization fails.
+
+## Scoped tools
+
+`toolfuncs` discovers tools from two roots:
+
+1. the nearest `.agents/tools` directory at or above the process's initial working directory;
+2. `~/.agents/tools`.
+
+An immediate child defines a tool only when it has one of these exact shapes:
+
+```text
+name.py                              # PEP 723 script metadata required
+
+name/
+  pyproject.toml
+  src/
+    name/
+      __init__.py
+```
+
+Both metadata containers require one static field:
+
+```toml
+[tool.toolfuncs]
+description = "Describe this tool in one line."
+```
+
+For the file form, that table is inside the PEP 723 `script` block. For the packaged form, `pyproject.toml` must also define a matching normalized `[project].name` and an explicit `[build-system]`. The tool directory name, scoped name, and Python import name are the same valid non-keyword identifier. Flat projects, direct package directories, single-module projects, namespace roots, legacy `setup.py` projects, artifacts, and remote URLs are not discoverable tool forms.
+
+A project tool shadows a user tool with the same name. The roots are captured when `toolfuncs` is first imported, so a long-running interpreter does not silently change its tool universe after `chdir()`.
+
+This supports the portable dynamic-import form:
+
+```python
+from toolfuncs import codexr
+
+agents = codexr.list_agents()
+```
+
+`from toolfuncs import name` is intentionally the portable form. `import toolfuncs.name` is not promised because scoped resolution is a dynamic package attribute rather than an installed `toolfuncs` submodule. Use `load_tool("name")` when a tool name conflicts with a `toolfuncs` API member.
+
+Universal CLI dispatch always works after installing `toolfuncs`:
+
+```console
+toolfuncs codexr list-agents
+toolfuncs run codexr list-agents
+```
+
+Run `toolfuncs sync` to add direct command shims for all currently visible tools to `~/.local/bin`, or choose another directory with `--bin-dir`. A shim performs scoped lookup again when invoked, so the same command correctly resolves project overrides. `sync` never overwrites an unmanaged command and does not remove older managed shims.
+
+## Composing tools
+
+A tool can import another scoped tool and call it like any Python module:
+
+```python
+from toolfuncs import codexr
+from toolfuncs import App
+
+app = App()
+
+
+@app.command
+def active_agent_ids() -> list[str]:
+    return [agent.session_id for agent in codexr.list_agents()]
+```
+
+Imported or undecorated functions are not exposed accidentally. Only functions registered on `app` become CLI commands; `__all__` retains its ordinary Python export meaning but does not define the command surface.
+
+## Importing arbitrary sources
+
+`import_path()` handles the following v1 source forms:
+
+| Source | Behavior |
+| --- | --- |
+| `tool.py` | executes directly; reads optional PEP 723 metadata |
+| `package/__init__.py` | imports `package` directly |
+| `package/` containing `__init__.py` | imports directly with relative imports and resources |
+| project containing `pyproject.toml` | builds one wheel, installs it, then imports its selected module |
+| project containing `setup.py` | builds one wheel through pip's legacy-project support |
+| `.whl` | inspects, installs, and imports the wheel |
+| source archive such as `.tar.gz` or `.zip` | builds, installs, and imports one wheel |
+| any of the above behind an fsspec URL | materializes the complete source and applies the same classification |
+
+Direct packages may declare dependencies in an adjacent `pyproject.toml` `[project]` table. PEP 723 metadata is read only from single Python files. Projects and artifacts leave dependency handling to their build metadata and pip.
+
+Regular projects are interpreted by their build backend rather than guessed from their directory tree. The resulting wheel is inspected for actual top-level Python imports. This supports conventional flat and `src` layouts for both modules and packages, as well as installed namespace packages. A bare `src/__init__.py` is not treated as a package layout.
+
+Import selection follows this order:
+
+1. explicit `import_name=`;
+2. a project directory name that matches an import in the built wheel;
+3. the wheel's sole top-level import.
+
+Ambiguous projects fail with their discovered candidates:
+
+```python
+from toolfuncs import import_path
+
+pillow = import_path("./vendor/Pillow", import_name="PIL")
+```
+
+`import_name=` belongs only to this generic utility. Discoverable packaged tools never configure or infer their import name; the scoped name is passed to `import_path()` internally.
+
+## Identity and execution environment
+
+Within one interpreter, a canonical source and import name identify one module object. Re-importing the same source returns that object, one source cannot be assigned two names, and one name cannot be assigned two sources. Direct dotted imports construct missing namespace parents, support relative imports, clean up after failed execution, and work with `importlib.reload()`.
+
+V1 installs dependencies and project wheels into the running interpreter environment under a process-wide import lock. This is deliberate: direct Python calls must receive the real module and Python objects rather than a proxy transport. It also means dependency conflicts are ordinary environment conflicts. Use a dedicated environment when mutually incompatible tools must coexist.
+
+Credentials in source URLs and opaque URL queries are removed from user-facing diagnostics. `storage_options=` is passed directly to fsspec and is never incorporated into module names.
+
+## Management commands
+
+```console
+toolfuncs list
+toolfuncs describe TOOL
+toolfuncs sync [--bin-dir DIRECTORY]
+toolfuncs TOOL [ARGS...]
+```
+
+`list`, `describe`, and `sync` emit strict JSON. `list` and `describe` read only static TOML metadata and never import tools, resolve their dependencies, or run build code. Their records contain `name`, `path`, `scope`, `kind`, and `description`. Use `toolfuncs TOOL --help` when runtime command inspection is needed.
+
+## Development
+
+```console
+uv sync
+uv run pytest
+uv run ruff format --check .
+uv run ruff check .
+uv run basedpyright
+```
+
+The detailed v1 guarantees and non-goals are recorded in [the contract](docs/contract.md).
+
+## Releasing
+
+The GitHub Release is the release control point. Set `[project].version`, merge and push that commit, then publish a GitHub Release whose tag is `v<version>`. The release workflow verifies that the tag and package version match, builds the wheel and source distribution, and publishes them to PyPI through the `pypi` environment and PyPI Trusted Publishing. It uses no long-lived PyPI token or repository secret.

toolfuncs-0.1.0/README.md

@@ -0,0 +1,194 @@
+# toolfuncs
+
+`toolfuncs` is a small function-calling convention for Python tools. A tool is a Python module whose typed public functions are its interface. The same functions can be called directly from Python or projected into a command-line interface without maintaining a second wrapper API.
+
+Discoverable tools live in a project or user-wide tool directory in one of two forms: a PEP 723 Python file or one packaged `src` project layout. The separate `import_path()` utility can load broader Python sources from local paths and fsspec URLs.
+
+## The basic model
+
+Write ordinary typed functions and register the CLI-callable operations on `toolfuncs.App`:
+
+```python
+#!/usr/bin/env -S uv run --script
+# /// script
+# requires-python = ">=3.11"
+# dependencies = ["toolfuncs"]
+# [tool.toolfuncs]
+# description = "Render values for another program."
+# ///
+
+from pathlib import Path
+
+from toolfuncs import App
+
+app = App()
+
+
+@app.command
+def render(value: str, *, output: Path | None = None) -> dict[str, object]:
+    """Return a value and its optional output path."""
+
+    return {"value": value, "output": output}
+
+
+if __name__ == "__main__":
+    app()
+```
+
+The Python interface is the definition:
+
+```python
+from pathlib import Path
+
+from toolfuncs import renderer
+
+result = renderer.render("hello", output=Path("result.txt"))
+```
+
+The CLI is derived from that same signature and returns strict JSON:
+
+```console
+$ toolfuncs renderer render hello --output result.txt
+{"value": "hello", "output": "result.txt"}
+```
+
+`toolfuncs` directly depends on Cyclopts and `pydantic-core`. Its `App` is a Cyclopts app with the established strict-JSON result action as its default, so a tool imports only `toolfuncs` rather than importing and configuring those libraries itself. `Parameter`, `Token`, `Group`, `validators`, `types`, and `to_jsonable_python` are also re-exported for tools that need the corresponding advanced behavior. Passing `result_action=` explicitly preserves Cyclopts' ordinary override behavior for streaming or domain-specific status policies.
+
+The decorator registers the original function without wrapping it. Direct Python calls therefore receive the original object and exceptions. CLI calls parse annotated values, emit one JSON value on stdout, and fail nonzero when parsing, execution, or serialization fails.
+
+## Scoped tools
+
+`toolfuncs` discovers tools from two roots:
+
+1. the nearest `.agents/tools` directory at or above the process's initial working directory;
+2. `~/.agents/tools`.
+
+An immediate child defines a tool only when it has one of these exact shapes:
+
+```text
+name.py                              # PEP 723 script metadata required
+
+name/
+  pyproject.toml
+  src/
+    name/
+      __init__.py
+```
+
+Both metadata containers require one static field:
+
+```toml
+[tool.toolfuncs]
+description = "Describe this tool in one line."
+```
+
+For the file form, that table is inside the PEP 723 `script` block. For the packaged form, `pyproject.toml` must also define a matching normalized `[project].name` and an explicit `[build-system]`. The tool directory name, scoped name, and Python import name are the same valid non-keyword identifier. Flat projects, direct package directories, single-module projects, namespace roots, legacy `setup.py` projects, artifacts, and remote URLs are not discoverable tool forms.
+
+A project tool shadows a user tool with the same name. The roots are captured when `toolfuncs` is first imported, so a long-running interpreter does not silently change its tool universe after `chdir()`.
+
+This supports the portable dynamic-import form:
+
+```python
+from toolfuncs import codexr
+
+agents = codexr.list_agents()
+```
+
+`from toolfuncs import name` is intentionally the portable form. `import toolfuncs.name` is not promised because scoped resolution is a dynamic package attribute rather than an installed `toolfuncs` submodule. Use `load_tool("name")` when a tool name conflicts with a `toolfuncs` API member.
+
+Universal CLI dispatch always works after installing `toolfuncs`:
+
+```console
+toolfuncs codexr list-agents
+toolfuncs run codexr list-agents
+```
+
+Run `toolfuncs sync` to add direct command shims for all currently visible tools to `~/.local/bin`, or choose another directory with `--bin-dir`. A shim performs scoped lookup again when invoked, so the same command correctly resolves project overrides. `sync` never overwrites an unmanaged command and does not remove older managed shims.
+
+## Composing tools
+
+A tool can import another scoped tool and call it like any Python module:
+
+```python
+from toolfuncs import codexr
+from toolfuncs import App
+
+app = App()
+
+
+@app.command
+def active_agent_ids() -> list[str]:
+    return [agent.session_id for agent in codexr.list_agents()]
+```
+
+Imported or undecorated functions are not exposed accidentally. Only functions registered on `app` become CLI commands; `__all__` retains its ordinary Python export meaning but does not define the command surface.
+
+## Importing arbitrary sources
+
+`import_path()` handles the following v1 source forms:
+
+| Source | Behavior |
+| --- | --- |
+| `tool.py` | executes directly; reads optional PEP 723 metadata |
+| `package/__init__.py` | imports `package` directly |
+| `package/` containing `__init__.py` | imports directly with relative imports and resources |
+| project containing `pyproject.toml` | builds one wheel, installs it, then imports its selected module |
+| project containing `setup.py` | builds one wheel through pip's legacy-project support |
+| `.whl` | inspects, installs, and imports the wheel |
+| source archive such as `.tar.gz` or `.zip` | builds, installs, and imports one wheel |
+| any of the above behind an fsspec URL | materializes the complete source and applies the same classification |
+
+Direct packages may declare dependencies in an adjacent `pyproject.toml` `[project]` table. PEP 723 metadata is read only from single Python files. Projects and artifacts leave dependency handling to their build metadata and pip.
+
+Regular projects are interpreted by their build backend rather than guessed from their directory tree. The resulting wheel is inspected for actual top-level Python imports. This supports conventional flat and `src` layouts for both modules and packages, as well as installed namespace packages. A bare `src/__init__.py` is not treated as a package layout.
+
+Import selection follows this order:
+
+1. explicit `import_name=`;
+2. a project directory name that matches an import in the built wheel;
+3. the wheel's sole top-level import.
+
+Ambiguous projects fail with their discovered candidates:
+
+```python
+from toolfuncs import import_path
+
+pillow = import_path("./vendor/Pillow", import_name="PIL")
+```
+
+`import_name=` belongs only to this generic utility. Discoverable packaged tools never configure or infer their import name; the scoped name is passed to `import_path()` internally.
+
+## Identity and execution environment
+
+Within one interpreter, a canonical source and import name identify one module object. Re-importing the same source returns that object, one source cannot be assigned two names, and one name cannot be assigned two sources. Direct dotted imports construct missing namespace parents, support relative imports, clean up after failed execution, and work with `importlib.reload()`.
+
+V1 installs dependencies and project wheels into the running interpreter environment under a process-wide import lock. This is deliberate: direct Python calls must receive the real module and Python objects rather than a proxy transport. It also means dependency conflicts are ordinary environment conflicts. Use a dedicated environment when mutually incompatible tools must coexist.
+
+Credentials in source URLs and opaque URL queries are removed from user-facing diagnostics. `storage_options=` is passed directly to fsspec and is never incorporated into module names.
+
+## Management commands
+
+```console
+toolfuncs list
+toolfuncs describe TOOL
+toolfuncs sync [--bin-dir DIRECTORY]
+toolfuncs TOOL [ARGS...]
+```
+
+`list`, `describe`, and `sync` emit strict JSON. `list` and `describe` read only static TOML metadata and never import tools, resolve their dependencies, or run build code. Their records contain `name`, `path`, `scope`, `kind`, and `description`. Use `toolfuncs TOOL --help` when runtime command inspection is needed.
+
+## Development
+
+```console
+uv sync
+uv run pytest
+uv run ruff format --check .
+uv run ruff check .
+uv run basedpyright
+```
+
+The detailed v1 guarantees and non-goals are recorded in [the contract](docs/contract.md).
+
+## Releasing
+
+The GitHub Release is the release control point. Set `[project].version`, merge and push that commit, then publish a GitHub Release whose tag is `v<version>`. The release workflow verifies that the tag and package version match, builds the wheel and source distribution, and publishes them to PyPI through the `pypi` environment and PyPI Trusted Publishing. It uses no long-lived PyPI token or repository secret.

toolfuncs-0.1.0/docs/contract.md

@@ -0,0 +1,70 @@
+# toolfuncs v1 contract
+
+## Purpose
+
+`toolfuncs` makes a Python function interface callable through two projections without defining two domain APIs. Python import and CLI invocation differ only at their unavoidable transport boundaries: CLI strings become annotated Python values, returned objects become strict JSON, and exceptions become nonzero process failures.
+
+This is intentionally a convention and implementation, not a transport protocol or registry specification. It occupies a lower level than MCP: a tool is executable Python in the caller's interpreter, and composition is an ordinary function call.
+
+## Authoring contract
+
+A tool is one Python module. Its authoritative operations are typed functions registered directly on a module-level `app`.
+
+- Define `app = toolfuncs.App()` and decorate each CLI-callable operation with `@app.command`.
+- `toolfuncs.App` is a Cyclopts App whose default result action serializes through `pydantic-core` as strict JSON. An explicit `result_action=` replaces that default unchanged.
+- `toolfuncs` re-exports the Cyclopts and `pydantic-core` authoring values needed by tools, so the tool does not import those libraries separately.
+- Only registered functions form the CLI surface. `__all__` has its ordinary Python meaning and does not register commands.
+- Function signatures, annotations, defaults, return values, docstrings, side effects, and exceptions define the operation.
+- `[tool.toolfuncs].description` contains the required one-line static tool description. Custom metadata dunders are not part of the contract.
+- Importing a tool must not execute an operation, print, configure process-wide state, or exit.
+- `app()` belongs behind `if __name__ == "__main__":` when the source should also be directly executable.
+
+CLI command and option spelling follows Cyclopts' deterministic Python-to-kebab-case projection. Successful CLI operations emit one strict JSON value. No fallback converts unknown values to strings, and non-finite floats are rejected.
+
+## Scope contract
+
+The effective tool set is the merge of the nearest ancestor `.agents/tools` directory over `~/.agents/tools`. Only valid immediate PEP 723 files and packaged project directories participate. Project definitions shadow user definitions by logical name. A logical name must be a valid non-keyword Python identifier.
+
+The initial working directory and home directory are frozen at the first `toolfuncs` import. Explicit `cwd=` and `home=` parameters exist on discovery APIs for deterministic inspection and testing; they do not mutate the frozen default context.
+
+## Discoverable source contract
+
+Exactly two source shapes define scoped tools:
+
+1. `<name>.py` contains one PEP 723 `script` block with `[tool.toolfuncs].description`;
+2. `<name>/` contains `pyproject.toml` and `src/<name>/__init__.py`.
+
+For a packaged tool, `[project].name` must normalize to `<name>`, `[build-system]` must explicitly declare `requires` and `build-backend`, and `[tool.toolfuncs].description` must be present. The directory name, scoped name, and Python import name are exactly `<name>`. Tool loading passes that known name to the generic importer; there is no tool-level import-name inference or configuration.
+
+Any immediate `.py` file or directory in a tool root that does not satisfy one of these contracts is invalid. In particular, direct package directories, flat projects, `src/<name>.py`, namespace roots, legacy `setup.py` projects, wheels, source archives, and remote sources are not discoverable tool forms.
+
+`toolfuncs list` and `toolfuncs describe` parse static metadata without importing source, resolving runtime dependencies, or invoking a build backend. Exact runtime commands remain defined by the module's `app` and are inspected through `toolfuncs <name> --help`.
+
+## Generic import utility
+
+`import_path()` remains broader than the tool convention. It accepts direct Python files and packages, installable `pyproject.toml` and legacy `setup.py` projects, wheels, source archives, and corresponding fsspec URLs. Direct packages read dependencies only from adjacent `[project]` metadata. Projects and artifacts are reduced to one wheel, whose installed Python roots are inspected for import selection.
+
+An arbitrary caller may pass explicit `import_name=` when the source does not have one unambiguous import. `import_path()` does not read `[tool.toolfuncs].import-name` or any other project configuration for this purpose.
+
+## Identity contract
+
+One interpreter maintains a bijection between canonical sources and registered import names. Repeating a pair returns the same module. Attempting to bind either side to a different counterpart raises `ImportConflictError`.
+
+Local source identity is its expanded absolute path. Remote source identity retains protocol, host, path, query, and fragment but removes URL user information. User-facing remote diagnostics additionally remove query strings. Storage credentials are neither identity nor metadata.
+
+An already loaded `sys.modules` entry that toolfuncs does not own is a conflict for a direct or installed import. V1 does not guess whether that module came from the same distribution.
+
+## Installation contract
+
+PEP 723 and direct-package dependencies are installed with the running interpreter's `pip`. Packaged tools, generic projects, and source archives are built to a wheel with `pip wheel --no-deps`; the selected wheel is then installed with pip so its declared runtime dependencies are resolved normally. Imports are invalidated after environment changes.
+
+Resolution, materialization, dependency installation, module registration, and execution are serialized by one reentrant process lock. Failed direct execution removes its module and any synthetic parent packages that remain unused.
+
+## Explicit v1 non-goals
+
+- No subprocess, RPC, or object-proxy isolation.
+- No dependency solver spanning several tools before import.
+- No alternate discoverable project layouts or tool-level import-name escape hatch.
+- No portable promise for `import toolfuncs.NAME`; use `from toolfuncs import NAME`.
+- No automatic shell-profile edits or daemon. `sync` creates additive shims only.
+- No `TOOL.md` or command manifest. Static TOML describes the tool; Python definitions remain authoritative for runtime operations.

toolfuncs-0.1.0/pyproject.toml

@@ -0,0 +1,51 @@
+[project]
+name = "toolfuncs"
+version = "0.1.0"
+description = "Function-first Python tools with matching import and command-line interfaces"
+readme = "README.md"
+authors = [
+    { name = "Nima Shoghi", email = "nima@boltz.bio" }
+]
+requires-python = ">=3.11"
+dependencies = [
+    "cyclopts>=4.23.2,<5",
+    "fsspec[github,http]>=2025.3.0",
+    "packaging>=24",
+    "pip>=25",
+    "pydantic-core>=2.20,<3",
+]
+
+[project.scripts]
+toolfuncs = "toolfuncs.__main__:main"
+
+[project.urls]
+Repository = "https://github.com/nimashoghi/toolfuncs"
+Issues = "https://github.com/nimashoghi/toolfuncs/issues"
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[dependency-groups]
+dev = [
+    "basedpyright>=1.31",
+    "build>=1.2",
+    "pytest>=8",
+    "pytest-cov>=6",
+    "ruff>=0.12",
+]
+
+[tool.ruff]
+line-length = 100
+target-version = "py311"
+
+[tool.ruff.lint]
+select = ["E", "F", "I", "UP", "B", "SIM", "RUF"]
+
+[tool.pytest.ini_options]
+addopts = "-ra"
+testpaths = ["tests"]
+
+[tool.basedpyright]
+pythonVersion = "3.11"
+typeCheckingMode = "standard"