hectiqlab 0.1.0__tar.gz

hectiqlab-0.1.0/.gitignore

@@ -0,0 +1,281 @@
+# Created by https://www.toptal.com/developers/gitignore/api/vue,nextjs,vuejs,python
+# Edit at https://www.toptal.com/developers/gitignore?templates=vue,nextjs,vuejs,python
+
+### NextJS ###
+# dependencies
+/node_modules
+/.pnp
+.pnp.js
+
+# testing
+/coverage
+
+# next.js
+/.next/
+/out/
+
+# production
+/build
+
+# misc
+.DS_Store
+*.pem
+
+# debug
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+.pnpm-debug.log*
+
+# local env files
+.env*.local
+
+# vercel
+.vercel
+
+# typescript
+*.tsbuildinfo
+next-env.d.ts
+
+### Python ###
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/#use-with-ide
+.pdm.toml
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+dev
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+### Python Patch ###
+# Poetry local configuration file - https://python-poetry.org/docs/configuration/#local-configuration
+poetry.toml
+
+# ruff
+.ruff_cache/
+
+# LSP config files
+pyrightconfig.json
+
+### Vue ###
+# gitignore template for Vue.js projects
+#
+# Recommended template: Node.gitignore
+
+# TODO: where does this rule come from?
+docs/_book
+
+# TODO: where does this rule come from?
+test/
+
+### Vuejs ###
+# Recommended template: Node.gitignore
+
+node_modules/
+npm-debug.log
+yarn-error.log
+
+# End of https://www.toptal.com/developers/gitignore/api/vue,nextjs,vuejs,python
+
+
+### VSCode ###
+.vscode/*
+*.code-workspace
+# Created by https://www.toptal.com/developers/gitignore/api/terraform
+# Edit at https://www.toptal.com/developers/gitignore?templates=terraform
+
+### Terraform ###
+# Local .terraform directories
+**/.terraform/*
+
+# .tfstate files
+*.tfstate
+*.tfstate.*
+
+# Crash log files
+crash.log
+crash.*.log
+
+# Exclude all .tfvars files, which are likely to contain sensitive data, such as
+# password, private keys, and other secrets. These should not be part of version
+# control as they are data points which are potentially sensitive and subject
+# to change depending on the environment.
+*.tfvars
+*.tfvars.json
+
+# Ignore override files as they are usually used to override resources locally and so
+# are not checked in
+override.tf
+override.tf.json
+*_override.tf
+*_override.tf.json
+
+# Include override files you do wish to add to version control using negated pattern
+# !example_override.tf
+
+# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
+# example: *tfplan*
+
+# Ignore CLI configuration files
+.terraformrc
+terraform.rc
+
+# End of https://www.toptal.com/developers/gitignore/api/terraform
+
+## Dev scripts
+dev.ipynb
+dev.py

hectiqlab-0.1.0/.python-version

@@ -0,0 +1 @@
+3.13

hectiqlab-0.1.0/PKG-INFO

@@ -0,0 +1,122 @@
+Metadata-Version: 2.5
+Name: hectiqlab
+Version: 0.1.0
+Summary: Record runs, stages, metrics, datasets and models to Hectiq Lab, from a script or the command line.
+Requires-Python: >=3.10
+Requires-Dist: httpx>=0.27
+Requires-Dist: pydantic-settings>=2.3
+Requires-Dist: pydantic>=2.7
+Requires-Dist: rich>=13.7
+Requires-Dist: tomli>=2.0; python_version < '3.11'
+Provides-Extra: cli
+Requires-Dist: typer>=0.12; extra == 'cli'
+Provides-Extra: parquet
+Requires-Dist: pyarrow>=15; extra == 'parquet'
+Provides-Extra: tui
+Requires-Dist: textual-plotext>=1.0; extra == 'tui'
+Requires-Dist: textual>=8.2; extra == 'tui'
+Requires-Dist: typer>=0.12; extra == 'tui'
+Description-Content-Type: text/markdown
+
+# hectiqlab
+
+Record runs, stages, metrics, datasets and models to [Hectiq Lab](https://lab.hectiq.ai), from a training script or the command line. Everything goes to the API the web app reads, over HTTP, from one background thread, so a training loop never waits on the network.
+
+This package lives beside `pyhectiqlab` (in `sdk/`) and does not replace it: both can be installed together, and they share `~/.hectiq-lab/credentials.toml`.
+
+```bash
+pip install hectiqlab                 # the SDK
+pip install "hectiqlab[cli]"          # and the `hlab` command line
+pip install "hectiqlab[tui]"          # and the dashboard `hlab ui` opens
+pip install "hectiqlab[tui,parquet]"  # and parquet previews in it, which take pyarrow
+```
+
+## A script
+
+```python
+import hectiqlab as hl
+
+with hl.run(
+    "two-tower, 3 epochs",
+    category="training",
+    tags=["linear:ENG-42"],
+    config={"lr": 1e-3, "epochs": 3},
+):
+    data = hl.datasets.get("interactions").unwrap()
+    hl.datasets.attach(data.id)
+    with hl.stage("train"):
+        for epoch in hl.each(range(3), "epoch"):
+            loss = train_one_epoch()
+            hl.add_metric("loss", step=epoch, value=loss)
+    hl.models.create("checkpoints/", name="two-tower").result()
+```
+
+A run captures its commit, branch, diff, installed packages, machine and command line as it opens, and ends `completed`, `failed` (with its traceback) or `stopped`, whether it was opened with `with` or left open until the script crashed or exited. One exit it cannot see: a run opened without `with` in a script that calls `sys.exit(1)` ends `completed`, because Python never hands a `SystemExit` to the exception hook; open the run with `with` to record the exit status. Stages nest: a `with`, a decorated function or a named `each` opens a stage inside whatever is open. Reads and changes return a `Result`; uploads and downloads return a `Future`, and an upload made while a run is open holds the run open until it lands, however long that takes (the bar shows it moving; Ctrl-C ends the run `stopped` without it).
+
+An API that is down, slow or refusing never raises in the middle of a training loop: a failed read or change is an `Err`, and what a run recorded that did not land is said once, as a warning, when the run closes (`run.result()` raises it instead). A mistake in the call itself does raise, at once: a metric or a stage with no run open, a category the web app does not know.
+
+Uploads and downloads draw a progress bar on stderr when it is a terminal. `progress=False` on the call, or `HECTIQLAB_PROGRESS=false`, draws none; `progress=True` draws one anyway.
+
+The project comes from `project=`, `hl.set_project(...)`, `HECTIQLAB_PROJECT`, or the `.hectiqlab/config.toml` that `hlab init` writes. `HECTIQLAB_DISABLE=1`, or a `RANK`/`LOCAL_RANK` other than 0, records nothing.
+
+A tag written `linear:ENG-42` speaks to that Linear issue, and `linear:project:<slug>` to a Linear project (the slug is the end of the project's Linear address). A run carrying one comments there when it starts, when it ends, and when the tag is attached; a dataset or a model version comments when such a tag is attached to it, which is how a deliverable is marked. Creating a version or removing a tag says nothing, and a bare `ENG-42` or `GPT-4` never speaks to Linear. The key belongs to the project, since a client's project comments in the client's Linear: `hlab login --linear -p org/project` keeps it in the credentials file as `[linear."org/project"]`, and `LINEAR_API_KEY` overrides it for one process. A project without a key comments nowhere; there is no key shared by every project.
+
+## The command line
+
+```bash
+hlab login                      # make a key with your email and password
+hlab init hectiq-ai/recsys      # this checkout records to that project
+hlab run list --tag linear:ENG-42
+hlab run get 42 --json          # runs are named by their rank, or their id
+hlab run stages 42
+hlab run tag 42 best            # dataset and model tag the same way
+hlab metric get 42 loss
+hlab dataset create data/ --name interactions --no-upload
+hlab model download two-tower --version 1.3
+hlab artifact get art_4f2c
+```
+
+Every command that reads or changes something takes `--json`, and prints one JSON document on stdout; prompts and progress bars go to stderr.
+
+## The dashboard
+
+`hlab ui` opens a terminal dashboard onto a project, `hectiqlab.tui`; `?` lists the keys. It opens on the project the SDK would record to (`-p`, `HECTIQLAB_PROJECT`, or `.hectiqlab/config.toml`), and on the switcher when nothing names one; `P` switches from anywhere. `1` to `5` are the dashboard, runs, datasets, models and tags.
+
+Everything it shows comes from the API the web app reads, through the SDK's own read functions: it refreshes every second, and reads the series of the open runs and of those that ended in the last fourteen days, a hundred runs to a request. It reads only the series on screen: an older run's come when it is opened. An open run that has given no sign of life for an hour, no change to its row, no sample, no stage, is shown as silent and read once a minute. A file previews over its signed address a range at a time, so a 20 GB parquet shows its schema, its row count and its first rows without being downloaded; without the `parquet` extra, a parquet says what to install instead.
+
+A screen (`tui/screens/`, built from `tui/widgets/`) never calls the SDK. It asks `tui/reads/`, and draws the SDK's own records. Importing `hectiqlab` never imports the dashboard.
+
+## Development
+
+```bash
+cd sdk_v2
+uv sync
+uv run ruff check . && uv run ruff format --check . && uv run ty check && uv run lint-imports
+uv run pytest -m "not integration"
+```
+
+The integration tests talk to the API running in `api/compose.yaml`, logged in as the user they seed it with, whose email and password come from your environment. They are skipped when the stack is not up or the login is not set, and fail instead with `HECTIQLAB_INTEGRATION=required`, as in CI:
+
+```bash
+docker compose -f ../api/compose.yaml up -d --build
+export HECTIQLAB_TEST_EMAIL=you@example.com HECTIQLAB_TEST_PASSWORD=...  # 8+ chars, upper, lower, digit
+uv run pytest -m integration
+```
+
+The stack, its login, the fresh key and project each test gets, and the clean process every test starts from are in `testing/hectiqlab_stack.py`, a pytest plugin every test loads. It is not part of the wheel. The dashboard's tests, in `tests/tui/`, read a seeded project instead of the API, except those in `tests/tui/integration/`.
+
+On a pull request that touches `api/` or `sdk_v2/`, `.github/workflows/hectiqlab_checks.yml` runs these checks and the unit tests on Python 3.10 and 3.13, and the integration tests against one stack.
+
+## Releasing
+
+`hectiqlab` is one package, the SDK, the command line and the dashboard at one version. A release is one button: **Actions → Release hectiqlab → Run workflow** on `main`, picking `patch`, `minor` or `major` (or `gh workflow run release_hectiqlab.yml -f bump=minor`).
+
+The workflow (`.github/workflows/release_hectiqlab.yml`) runs the checks, including the integration tests; moves the version and re-locks; builds the package and checks its metadata; commits `Release hectiqlab X.Y.Z` to `main` and tags it `hectiqlab-vX.Y.Z`; creates the GitHub release with the subjects of the commits under `sdk_v2/` since the last release; then publishes it to PyPI. Nobody edits a version by hand. If only the publishing fails, re-running that job publishes the distributions already built.
+
+The version steps live in `.github/scripts/release_hectiqlab.py`, which runs the same on a clone (`bump`, `notes`, `check`).
+
+Once, before the first release, and close together, because a pending publisher does not reserve the name ([PyPI docs](https://docs.pypi.org/trusted-publishers/creating-a-project-through-oidc/)):
+
+1. On pypi.org, under your account's **Publishing** page, add a GitHub Actions pending publisher for the project `hectiqlab`: repository `HectiqAI/hectiq-lab-revision`, workflow `release_hectiqlab.yml`, environment `pypi`.
+2. In the repository's settings, create the `pypi` environment. Required reviewers on it make every release wait for an approval before it publishes.
+3. Run the first release. It ships the version the pyproject already declares, `0.1.0`, whichever bump is picked; every release after it bumps.

hectiqlab-0.1.0/README.md

@@ -0,0 +1,102 @@
+# hectiqlab
+
+Record runs, stages, metrics, datasets and models to [Hectiq Lab](https://lab.hectiq.ai), from a training script or the command line. Everything goes to the API the web app reads, over HTTP, from one background thread, so a training loop never waits on the network.
+
+This package lives beside `pyhectiqlab` (in `sdk/`) and does not replace it: both can be installed together, and they share `~/.hectiq-lab/credentials.toml`.
+
+```bash
+pip install hectiqlab                 # the SDK
+pip install "hectiqlab[cli]"          # and the `hlab` command line
+pip install "hectiqlab[tui]"          # and the dashboard `hlab ui` opens
+pip install "hectiqlab[tui,parquet]"  # and parquet previews in it, which take pyarrow
+```
+
+## A script
+
+```python
+import hectiqlab as hl
+
+with hl.run(
+    "two-tower, 3 epochs",
+    category="training",
+    tags=["linear:ENG-42"],
+    config={"lr": 1e-3, "epochs": 3},
+):
+    data = hl.datasets.get("interactions").unwrap()
+    hl.datasets.attach(data.id)
+    with hl.stage("train"):
+        for epoch in hl.each(range(3), "epoch"):
+            loss = train_one_epoch()
+            hl.add_metric("loss", step=epoch, value=loss)
+    hl.models.create("checkpoints/", name="two-tower").result()
+```
+
+A run captures its commit, branch, diff, installed packages, machine and command line as it opens, and ends `completed`, `failed` (with its traceback) or `stopped`, whether it was opened with `with` or left open until the script crashed or exited. One exit it cannot see: a run opened without `with` in a script that calls `sys.exit(1)` ends `completed`, because Python never hands a `SystemExit` to the exception hook; open the run with `with` to record the exit status. Stages nest: a `with`, a decorated function or a named `each` opens a stage inside whatever is open. Reads and changes return a `Result`; uploads and downloads return a `Future`, and an upload made while a run is open holds the run open until it lands, however long that takes (the bar shows it moving; Ctrl-C ends the run `stopped` without it).
+
+An API that is down, slow or refusing never raises in the middle of a training loop: a failed read or change is an `Err`, and what a run recorded that did not land is said once, as a warning, when the run closes (`run.result()` raises it instead). A mistake in the call itself does raise, at once: a metric or a stage with no run open, a category the web app does not know.
+
+Uploads and downloads draw a progress bar on stderr when it is a terminal. `progress=False` on the call, or `HECTIQLAB_PROGRESS=false`, draws none; `progress=True` draws one anyway.
+
+The project comes from `project=`, `hl.set_project(...)`, `HECTIQLAB_PROJECT`, or the `.hectiqlab/config.toml` that `hlab init` writes. `HECTIQLAB_DISABLE=1`, or a `RANK`/`LOCAL_RANK` other than 0, records nothing.
+
+A tag written `linear:ENG-42` speaks to that Linear issue, and `linear:project:<slug>` to a Linear project (the slug is the end of the project's Linear address). A run carrying one comments there when it starts, when it ends, and when the tag is attached; a dataset or a model version comments when such a tag is attached to it, which is how a deliverable is marked. Creating a version or removing a tag says nothing, and a bare `ENG-42` or `GPT-4` never speaks to Linear. The key belongs to the project, since a client's project comments in the client's Linear: `hlab login --linear -p org/project` keeps it in the credentials file as `[linear."org/project"]`, and `LINEAR_API_KEY` overrides it for one process. A project without a key comments nowhere; there is no key shared by every project.
+
+## The command line
+
+```bash
+hlab login                      # make a key with your email and password
+hlab init hectiq-ai/recsys      # this checkout records to that project
+hlab run list --tag linear:ENG-42
+hlab run get 42 --json          # runs are named by their rank, or their id
+hlab run stages 42
+hlab run tag 42 best            # dataset and model tag the same way
+hlab metric get 42 loss
+hlab dataset create data/ --name interactions --no-upload
+hlab model download two-tower --version 1.3
+hlab artifact get art_4f2c
+```
+
+Every command that reads or changes something takes `--json`, and prints one JSON document on stdout; prompts and progress bars go to stderr.
+
+## The dashboard
+
+`hlab ui` opens a terminal dashboard onto a project, `hectiqlab.tui`; `?` lists the keys. It opens on the project the SDK would record to (`-p`, `HECTIQLAB_PROJECT`, or `.hectiqlab/config.toml`), and on the switcher when nothing names one; `P` switches from anywhere. `1` to `5` are the dashboard, runs, datasets, models and tags.
+
+Everything it shows comes from the API the web app reads, through the SDK's own read functions: it refreshes every second, and reads the series of the open runs and of those that ended in the last fourteen days, a hundred runs to a request. It reads only the series on screen: an older run's come when it is opened. An open run that has given no sign of life for an hour, no change to its row, no sample, no stage, is shown as silent and read once a minute. A file previews over its signed address a range at a time, so a 20 GB parquet shows its schema, its row count and its first rows without being downloaded; without the `parquet` extra, a parquet says what to install instead.
+
+A screen (`tui/screens/`, built from `tui/widgets/`) never calls the SDK. It asks `tui/reads/`, and draws the SDK's own records. Importing `hectiqlab` never imports the dashboard.
+
+## Development
+
+```bash
+cd sdk_v2
+uv sync
+uv run ruff check . && uv run ruff format --check . && uv run ty check && uv run lint-imports
+uv run pytest -m "not integration"
+```
+
+The integration tests talk to the API running in `api/compose.yaml`, logged in as the user they seed it with, whose email and password come from your environment. They are skipped when the stack is not up or the login is not set, and fail instead with `HECTIQLAB_INTEGRATION=required`, as in CI:
+
+```bash
+docker compose -f ../api/compose.yaml up -d --build
+export HECTIQLAB_TEST_EMAIL=you@example.com HECTIQLAB_TEST_PASSWORD=...  # 8+ chars, upper, lower, digit
+uv run pytest -m integration
+```
+
+The stack, its login, the fresh key and project each test gets, and the clean process every test starts from are in `testing/hectiqlab_stack.py`, a pytest plugin every test loads. It is not part of the wheel. The dashboard's tests, in `tests/tui/`, read a seeded project instead of the API, except those in `tests/tui/integration/`.
+
+On a pull request that touches `api/` or `sdk_v2/`, `.github/workflows/hectiqlab_checks.yml` runs these checks and the unit tests on Python 3.10 and 3.13, and the integration tests against one stack.
+
+## Releasing
+
+`hectiqlab` is one package, the SDK, the command line and the dashboard at one version. A release is one button: **Actions → Release hectiqlab → Run workflow** on `main`, picking `patch`, `minor` or `major` (or `gh workflow run release_hectiqlab.yml -f bump=minor`).
+
+The workflow (`.github/workflows/release_hectiqlab.yml`) runs the checks, including the integration tests; moves the version and re-locks; builds the package and checks its metadata; commits `Release hectiqlab X.Y.Z` to `main` and tags it `hectiqlab-vX.Y.Z`; creates the GitHub release with the subjects of the commits under `sdk_v2/` since the last release; then publishes it to PyPI. Nobody edits a version by hand. If only the publishing fails, re-running that job publishes the distributions already built.
+
+The version steps live in `.github/scripts/release_hectiqlab.py`, which runs the same on a clone (`bump`, `notes`, `check`).
+
+Once, before the first release, and close together, because a pending publisher does not reserve the name ([PyPI docs](https://docs.pypi.org/trusted-publishers/creating-a-project-through-oidc/)):
+
+1. On pypi.org, under your account's **Publishing** page, add a GitHub Actions pending publisher for the project `hectiqlab`: repository `HectiqAI/hectiq-lab-revision`, workflow `release_hectiqlab.yml`, environment `pypi`.
+2. In the repository's settings, create the `pypi` environment. Required reviewers on it make every release wait for an approval before it publishes.
+3. Run the first release. It ships the version the pyproject already declares, `0.1.0`, whichever bump is picked; every release after it bumps.

hectiqlab-0.1.0/hectiqlab/__init__.py

@@ -0,0 +1,64 @@
+"""hectiqlab: record runs, stages, metrics, datasets and models to Hectiq Lab.
+
+Example::
+
+    import hectiqlab as hl
+
+    with hl.run("two-tower", category="training", config={"lr": 1e-3}):
+        for epoch in hl.each(range(3), "epoch"):
+            hl.add_metric("loss", step=epoch, value=train_one_epoch())
+"""
+
+from importlib.metadata import version
+
+from hectiqlab import artifacts, metrics, projects, records, runs, tags
+from hectiqlab.errors import (
+    LabAuthError,
+    LabConnectionError,
+    LabError,
+    LabNotFoundError,
+    LabServerError,
+    LabValidationError,
+    LabWarning,
+)
+from hectiqlab.metrics import add_metric
+from hectiqlab.projects.workspace import set_project
+from hectiqlab.result import Err, Ok, Result
+from hectiqlab.runs.factory import run
+from hectiqlab.runs.handle import Run
+from hectiqlab.session import shutdown
+from hectiqlab.stages.opening import each, stage
+from hectiqlab.stages.stage import Stage
+from hectiqlab.versioned import datasets, models
+
+__version__ = version("hectiqlab")
+
+__all__ = [
+    "Err",
+    "LabAuthError",
+    "LabConnectionError",
+    "LabError",
+    "LabNotFoundError",
+    "LabServerError",
+    "LabValidationError",
+    "LabWarning",
+    "Ok",
+    "Result",
+    "Run",
+    "Stage",
+    "__version__",
+    "add_metric",
+    "artifacts",
+    "datasets",
+    "each",
+    "metrics",
+    "models",
+    "projects",
+    "records",
+    "run",
+    "runs",
+    "set_project",
+    "shutdown",
+    "stage",
+    "tags",
+]

hectiqlab-0.1.0/hectiqlab/_internal/__init__.py

@@ -0,0 +1 @@
+"""The SDK's machinery: what every module of the package imports, and no user ever does."""