ato 2.0.2__py3-none-any.whl → 2.0.3__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Potentially problematic release.


This version of ato might be problematic. Click here for more details.

@@ -1,7 +1,7 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: ato
3
- Version: 2.0.2
4
- Summary: A minimal, composable config layer for Python and ML pipelines. Built to stay, not to impress.
3
+ Version: 2.0.3
4
+ Summary: A frameworkless integration layer for ML pipelines. Ato doesn't compete with frameworks — it restores freedom between them.
5
5
  Author: ato contributors
6
6
  License: MIT
7
7
  Project-URL: Homepage, https://github.com/yourusername/ato
@@ -34,73 +34,88 @@ Dynamic: license-file
34
34
 
35
35
  # Ato: A Tiny Orchestrator
36
36
 
37
- ## A minimal, composable config layer for Python and ML pipelines
37
+ ## A frameworkless integration layer for Python and ML pipelines
38
38
 
39
- Ato is a minimal, composable config system for Python and ML pipelines.
40
- It lets you **chain**, **merge**, and **freeze** modular configs,
41
- so you can move seamlessly from **dynamic experiments** to **static production builds**.
39
+ **Ato doesn't compete with frameworks it restores freedom between them.**
42
40
 
43
- Unlike heavy frameworks, Ato keeps everything **transparent** and **Pythonic** —
44
- you can use it alongside tools like Hydra, WandB, or MLflow without friction.
45
- It’s built for people who prefer clarity over magic.
41
+ Every framework tries to own your workflow.
42
+ Ato doesn't. It just gives you the **handles to connect them**.
46
43
 
47
- After all, *Ato* was never built to impress it was built to stay.
44
+ Unlike Hydra, MLflow, or W&Bwhich build ecosystems
45
+ Ato provides **structural boundaries** that let you compose, track, and optimize
46
+ without surrendering control to any single system.
47
+
48
+ You can:
49
+ - **Chain** configs from multiple sources (Hydra YAML, OpenMMLab, raw Python)
50
+ - **Merge** them with explicit priority control — and **debug** the exact merge order
51
+ - **Track** experiments in SQLite with zero setup — or sync to MLflow/W&B when you need dashboards
52
+ - **Optimize** hyperparameters with built-in Hyperband — or use Optuna/Ray Tune alongside
53
+
54
+ Ato keeps everything **transparent** and **Pythonic**.
55
+ No magic. No vendor lock-in. Just composable pieces you control.
48
56
 
49
57
  <details>
50
- <summary><strong>Developer’s Note</strong></summary>
51
-
52
- I didn’t know there was a great tool called Hydra.
53
- So I built something a bit simpler, a bit more opinionated,
54
- and maybe a bit more compatible — something that could also work nicely
55
- with amazing tools like Hydra, WandB, or MLflow.
56
-
57
- Even though I didn’t know these tools at the time,
58
- I deliberately designed for compatibility —
59
- and later, after learning about Hydra and others,
60
- I added explicit interop layers.
61
- Because I know how tempting and exhausting
62
- it can be to move from a familiar environment
63
- to a new, more attractive one.
64
-
65
- I’ve been the only user so far
66
- not because I wanted to hide it,
67
- but because I never had anyone around
68
- who could really tell me if it was good enough.
69
- Maybe this is the right time to find out.
70
-
71
- Sothere’s no need to compete.
72
- Just *try it once.*
73
- This tool won’t make you tired.
74
- It might even feel a little kind.
58
+ <summary><strong>Design Philosophy</strong></summary>
59
+
60
+ Ato was designed from a simple realization:
61
+ **frameworks solve composition, but they also create coupling.**
62
+
63
+ When I built Ato, I didn't know Hydra existed.
64
+ But I did know I wanted something that wouldn't **own** my workflow —
65
+ something that could **compose** with whatever came next.
66
+
67
+ That constraint led to three design principles:
68
+
69
+ 1. **Structural neutrality** Ato has no opinion on your stack.
70
+ It's a layer, not a platform.
71
+
72
+ 2. **Explicit boundaries** — Each module (ADict, Scope, SQLTracker, HyperOpt) is independent.
73
+ Use one, use all, or mix with other tools. No forced dependencies.
74
+
75
+ 3. **Debuggable composition** When configs merge from 5 sources, you should see **why** a value was set.
76
+ Ato's `manual` command shows the exact merge order a feature no other tool has.
77
+
78
+ This isn't minimalism for its own sake.
79
+ It's **structural restraint** interfering only where necessary,
80
+ and staying out of the way everywhere else.
75
81
 
76
82
  </details>
77
83
 
78
84
  ---
79
85
 
80
- **Ato** is designed to work *with* your existing tools — not replace them.
81
- It provides configuration management, experiment tracking, and hyperparameter optimization
82
- as a **philosophical layer** that plays nicely with Hydra, MLflow, W&B, and whatever else you use.
83
-
84
86
  ## Why Ato?
85
87
 
86
- Ato isn't trying to compete with Hydra or replace your experiment tracking platform.
87
- It's for the projects that live *before* things get complicated — or for teams that want clarity over features.
88
+ Ato solves a problem that frameworks create: **workflow ownership**.
89
+
90
+ | Framework Approach | Ato's Approach |
91
+ |-------------------|----------------|
92
+ | Hydra owns config composition | Ato **composes** Hydra configs + raw Python + CLI args |
93
+ | MLflow owns experiment tracking | Ato tracks locally in SQLite, **or** syncs to MLflow |
94
+ | W&B owns hyperparameter search | Ato provides Hyperband, **or** you use Optuna/Ray |
95
+ | Each framework wants to be **the** system | Ato is **a layer** you control |
96
+
97
+ **Ato is for teams who want:**
98
+ - Config flexibility without framework lock-in
99
+ - Experiment tracking without mandatory cloud platforms
100
+ - Hyperparameter optimization without opaque black boxes
101
+ - The ability to **change tools** without rewriting pipelines
88
102
 
89
- **Philosophy over framework**: Ato gives you enough structure to stay organized, without imposing a rigid system.
90
- Use it standalone, or layer it on top of Hydra, MLflow, or W&B. It's a tool, not a commitment.
103
+ ### What Makes Ato Structurally Different
91
104
 
92
- ### Core Differentiators
105
+ These aren't features — they're **architectural decisions** that frameworks can't replicate without breaking their own abstractions:
93
106
 
94
- - **True Namespace Isolation**: MultiScope provides independent config contexts (unique to Ato!)
95
- - **Configuration Transparency**: Visualize exact config merge order - debug configs with `manual` command
96
- - **Built-in Experiment Tracking**: SQLite-based tracking with no external services required
97
- - **Structural Hashing**: Track experiment structure changes automatically
107
+ | Capability | Why Frameworks Can't Do This | What It Enables |
108
+ |------------|------------------------------|-----------------|
109
+ | **MultiScope** (namespace isolation) | Frameworks use global config namespaces | Multiple teams can own separate config scopes without key collisions. No `model_lr` vs `data_lr` prefixing needed. |
110
+ | **`manual` command** (merge order debugging) | Frameworks show final configs, not merge logic | See **why** a value was set — trace exact merge order across defaults, named configs, CLI args, and lazy evaluation. |
111
+ | **Structural hashing** | Frameworks track values, not structure | Detect when experiment **architecture** changes (not just hyperparameters). Critical for reproducibility. |
112
+ | **Offline-first tracking** | Frameworks assume centralized platforms | Zero-setup SQLite tracking. No servers, no auth, no vendor lock-in. Sync to MLflow/W&B only when needed. |
98
113
 
99
114
  ### Developer Experience
100
115
 
101
- - **Zero Boilerplate**: Auto-nested configs, lazy evaluation, attribute access
102
- - **CLI-first Design**: Configure experiments from command line without touching code
103
- - **Framework Agnostic**: Works with PyTorch, TensorFlow, JAX, or pure Python
116
+ - **Zero boilerplate** Auto-nested configs (`cfg.model.backbone.depth = 50` just works), lazy evaluation, attribute access
117
+ - **CLI-first** Override any config from command line without touching code: `python train.py model.backbone=%resnet101%`
118
+ - **Framework agnostic** Works with PyTorch, TensorFlow, JAX, or pure Python. No framework-specific decorators or magic.
104
119
 
105
120
  ## Quick Start
106
121
 
@@ -142,7 +157,7 @@ if __name__ == '__main__':
142
157
  - [SQL Tracker: Experiment Tracking](#sql-tracker-experiment-tracking)
143
158
  - [Hyperparameter Optimization](#hyperparameter-optimization)
144
159
  - [Best Practices](#best-practices)
145
- - [Future Work](#future-work--optional-modular-non-intrusive)
160
+ - [Roadmap](#roadmap-expanding-boundaries-without-breaking-neutrality)
146
161
  - [Working with Existing Tools](#working-with-existing-tools)
147
162
 
148
163
  ---
@@ -1132,32 +1147,49 @@ MIT License
1132
1147
 
1133
1148
  ---
1134
1149
 
1135
- ## Future Work Optional, Modular, Non-Intrusive
1150
+ ## Roadmap: Expanding Boundaries Without Breaking Neutrality
1136
1151
 
1137
- We're planning to add an **HTML dashboard** (as a small local daemon) for teams that want visual exploration:
1152
+ Ato's design constraint is **structural neutrality** adding capabilities without creating dependencies.
1138
1153
 
1139
- **Planned features:**
1140
- - Metric comparison & trends
1154
+ ### Planned: Local Dashboard (Optional Module)
1155
+
1156
+ A lightweight HTML dashboard for teams that want visual exploration **without** committing to MLflow/W&B:
1157
+
1158
+ **What it adds:**
1159
+ - Metric comparison & trends (read-only view of SQLite data)
1141
1160
  - Run history & artifact browsing
1142
- - Configuration diffs (including structural hash visualization)
1161
+ - Config diff visualization (including structural hash changes)
1143
1162
  - Interactive hyperparameter analysis
1144
1163
 
1145
- **Philosophy stays the same:**
1146
- - **No hard dependency** - Ato core (Scope / ADict / SQL tracker / HyperOpt) works 100% without the dashboard
1147
- - **No coupling** - The dashboard is a separate process that reads from SQLite/logs; it doesn't block or modify your runs
1148
- - **Zero lock-in** - Remove the dashboard and nothing in your training code changes
1149
- - **Fully modular** - Pick only what you need
1164
+ **Design constraints:**
1165
+ - **No hard dependency** Ato core works 100% without the dashboard
1166
+ - **Separate process** Dashboard reads from SQLite; doesn't block or modify runs
1167
+ - **Zero lock-in** Remove the dashboard, and your training code doesn't change
1168
+ - **Composable** Use it alongside MLflow/W&B, or replace either one
1169
+
1170
+ ### Why This Fits Ato's Philosophy
1150
1171
 
1151
- **Example workflows:**
1172
+ The dashboard is **not** a platform — it's a **view** into data you already own (SQLite).
1152
1173
 
1153
- | What you need | What you use |
1174
+ | What It Doesn't Do | Why That Matters |
1175
+ |--------------------|------------------|
1176
+ | Doesn't store data | You can delete it without losing experiments |
1177
+ | Doesn't require auth | No accounts, no vendors, no network calls |
1178
+ | Doesn't modify configs | Pure read-only visualization |
1179
+ | Doesn't couple to Ato's core | Works with any SQLite database |
1180
+
1181
+ This preserves Ato's design principle: **provide handles, not ownership.**
1182
+
1183
+ ### Modular Adoption Path
1184
+
1185
+ | What You Need | What You Use |
1154
1186
  |---------------|--------------|
1155
- | Just configs | `ADict` + `Scope` only — no DB, no UI |
1156
- | Headless tracking | Add SQL tracker — still no UI |
1157
- | Visual exploration | Start dashboard daemon when you want; stop it and keep training |
1158
- | Full stack | Use everything, or mix with MLflow/W&B dashboards |
1187
+ | Just configs | `ADict` + `Scope` — no DB, no UI |
1188
+ | Headless tracking | Add SQLTracker — still no UI |
1189
+ | Local visualization | Add dashboard daemon run/stop anytime |
1190
+ | Team collaboration | Sync to MLflow/W&B dashboards |
1159
1191
 
1160
- **Guiding rule:** Ato is a set of small, composable tools — not a monolith. Use what helps; ignore the rest.
1192
+ **Guiding principle:** Ato remains a set of **independent, composable tools** — not a platform you commit to.
1161
1193
 
1162
1194
  ---
1163
1195
 
@@ -1177,14 +1209,26 @@ pip install -e .
1177
1209
 
1178
1210
  ## Working with Existing Tools
1179
1211
 
1180
- Ato isn't meant to replace Hydra, MLflow, or W&B — it's a **composable layer** you can use alongside them.
1212
+ **Ato is an integration layer, not a replacement.**
1213
+
1214
+ It's designed to **compose** with Hydra, MLflow, W&B, and whatever tools you already use.
1215
+ The goal isn't to compete — it's to **give you handles** for connecting systems without coupling your workflow to any single platform.
1216
+
1217
+ ### Composition Strategy
1218
+
1219
+ Ato provides three structural capabilities that frameworks don't:
1220
+
1221
+ | What Ato Adds | Why It Matters | How It Composes |
1222
+ |---------------|----------------|-----------------|
1223
+ | **MultiScope** | True namespace isolation | Multiple config sources (Hydra, raw Python, CLI) coexist without key collisions |
1224
+ | **`manual` command** | Config merge order visualization | Debug **why** a value was set — see exact merge order across all sources |
1225
+ | **Offline-first tracking** | Zero-setup SQLite tracking | Track locally, **then** sync to MLflow/W&B only when you need dashboards |
1181
1226
 
1182
- Think of Ato as a "config control surface" that gives you clarity and structure without forcing you into a framework.
1183
- Many teams use Ato for the 90% of experiments that don't need heavy infrastructure, then graduate to larger tools when needed.
1227
+ These aren't "features" they're **structural boundaries** that let you compose tools freely.
1184
1228
 
1185
- ### Ato + Hydra = Better Together
1229
+ ### Ato + Hydra: Designed to Compose
1186
1230
 
1187
- Ato has **built-in Hydra compatibility** via `compose_hierarchy()`:
1231
+ Ato has **native Hydra composition** via `compose_hierarchy()`:
1188
1232
 
1189
1233
  ```python
1190
1234
  from ato.adict import ADict
@@ -1197,65 +1241,74 @@ config = ADict.compose_hierarchy(
1197
1241
  overrides={'model.lr': 0.01}
1198
1242
  )
1199
1243
 
1200
- # Now add Ato's unique features on top:
1201
- # - MultiScope for namespace isolation
1202
- # - `manual` command for merge debugging
1203
- # - Built-in SQL tracking
1244
+ # Now add Ato's structural boundaries:
1245
+ # - MultiScope for independent namespaces
1246
+ # - `manual` command to debug merge order
1247
+ # - SQLite tracking without MLflow overhead
1204
1248
  ```
1205
1249
 
1206
- **Migration from Hydra** is literally just replacing `hydra.compose()` with `ADict.compose_hierarchy()`.
1250
+ **You're not replacing Hydra** you're **extending** it with namespace isolation and debuggable composition.
1207
1251
 
1208
- ### What Makes Ato Different?
1252
+ ### Integration Matrix
1209
1253
 
1210
- Ato focuses on **three unique capabilities** that complement existing tools:
1254
+ Ato is designed to work **between** frameworks:
1211
1255
 
1212
- | Feature | What It Solves | Why It Matters |
1213
- |---------|----------------|----------------|
1214
- | **MultiScope** | True namespace isolation | Multiple teams can own separate config scopes without key collisions (no `model_lr` vs `data_lr` prefixing needed) |
1215
- | **`manual` command** | Config merge order visualization | Debug *why* a config value is set — see exact merge order, not just final result |
1216
- | **Offline-first tracking** | Zero-setup SQLite tracking | Experiment tracking without servers, platforms, or external dependencies |
1256
+ | Tool | What It Owns | What Ato Adds |
1257
+ |------|--------------|---------------|
1258
+ | **Hydra** | Config composition from YAML | MultiScope (namespace isolation) + merge debugging |
1259
+ | **MLflow** | Centralized experiment platform | Local-first SQLite tracking + structural hashing |
1260
+ | **W&B** | Cloud-based tracking + dashboards | Offline tracking + sync when ready |
1261
+ | **OpenMMLab** | Config inheritance (`_base_`) | Direct import via `load_mm_config()` |
1262
+ | **Optuna/Ray Tune** | Advanced hyperparameter search | Built-in Hyperband + composable with their optimizers |
1217
1263
 
1218
- ### Compatibility Matrix
1264
+ ### Composition Patterns
1219
1265
 
1220
- Ato plays nicely with your existing stack:
1266
+ **Pattern 1: Ato as the integration layer**
1267
+ ```
1268
+ Hydra (config source) → Ato (composition + tracking) → MLflow (dashboards)
1269
+ ```
1221
1270
 
1222
- | Tool | Ato's Role | Integration |
1223
- |------|------------|-------------|
1224
- | **Hydra** | Extends with MultiScope + merge debugging | `compose_hierarchy()` loads Hydra configs directly |
1225
- | **MLflow** | Lightweight alternative for simple projects | Use Ato's SQL tracker for offline work, MLflow for dashboards |
1226
- | **W&B** | Offline-first complement | Track locally with Ato, sync to W&B when needed |
1227
- | **OpenMMLab** | Config migration layer | `load_mm_config()` handles `_base_` inheritance |
1228
- | **PyTorch/TF/JAX** | Framework-agnostic config + tracking | Works with any training framework |
1271
+ **Pattern 2: Ato for local development**
1272
+ ```
1273
+ Local experiments: Ato (full stack)
1274
+ Production: Ato MLflow (centralized tracking)
1275
+ ```
1276
+
1277
+ **Pattern 3: Gradual adoption**
1278
+ ```
1279
+ Start: Ato alone (zero dependencies)
1280
+ Scale: Add Hydra for complex configs
1281
+ Collaborate: Sync to W&B for team dashboards
1282
+ ```
1229
1283
 
1230
1284
  ### When to Use What
1231
1285
 
1232
- **Use Ato alone** for:
1233
- - Individual research experiments
1234
- - Projects that don't need a dashboard
1235
- - Teams wanting namespace isolation (MultiScope)
1236
- - Config merge debugging (`manual` command)
1286
+ **Use Ato alone** when:
1287
+ - You want zero external dependencies
1288
+ - You need namespace isolation (MultiScope)
1289
+ - You want to debug config merge order
1237
1290
 
1238
- **Use Ato + Hydra** when:
1239
- - You need Hydra's deep config hierarchies
1240
- - Your team already uses Hydra YAML structure
1241
- - You want MultiScope on top of Hydra's composition
1291
+ **Compose with Hydra** when:
1292
+ - Your team already has Hydra YAML configs
1293
+ - You need deep config hierarchies + namespace isolation
1294
+ - You want to see **why** a Hydra config set a value (`manual` command)
1242
1295
 
1243
- **Use Ato + MLflow/W&B** when:
1296
+ **Compose with MLflow/W&B** when:
1244
1297
  - You want local-first tracking with optional cloud sync
1245
- - You need Ato's structural hashing + offline SQLite
1246
- - Your team prefers MLflow/W&B dashboards for collaboration
1298
+ - You need structural hashing + offline SQLite
1299
+ - You're migrating between tracking platforms
1247
1300
 
1248
- **Graduate to pure MLflow/W&B** when:
1249
- - You need real-time dashboards and team collaboration UI
1250
- - Model registry and dataset versioning become critical
1251
- - Your experiments are production-facing
1301
+ **You don't need Ato** if:
1302
+ - You're fully committed to a single framework ecosystem
1303
+ - You don't need debuggable config composition
1304
+ - You never switch between tools
1252
1305
 
1253
1306
  ### What Ato Doesn't Do
1254
1307
 
1255
- Ato intentionally skips features that larger tools handle better:
1256
- - Real-time web dashboards (use MLflow/W&B)
1257
- - Model registry (use MLflow)
1258
- - Dataset versioning (use W&B/DVC)
1259
- - Deep plugin ecosystems (use Hydra)
1308
+ Ato intentionally **doesn't** build an ecosystem:
1309
+ - No web dashboards Use MLflow/W&B
1310
+ - No model registry Use MLflow
1311
+ - No dataset versioning Use DVC/W&B
1312
+ - No plugin marketplace Use Hydra
1260
1313
 
1261
- Ato's philosophy: **give you enough structure to stay organized, without becoming infrastructure.**
1314
+ **Ato's goal:** Stay out of your way. Provide handles. Let you change tools without rewriting code.
@@ -11,8 +11,8 @@ ato/db_routers/sql/schema.py,sha256=3eRF1oMnoebEh1QA39aqgcnTSe0h9JAXBfExAD0sPGY,
11
11
  ato/hyperopt/__init__.py,sha256=47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU,0
12
12
  ato/hyperopt/base.py,sha256=Wtu3l9FPB32exoUYEHKQf3r19U_l24_i-rle429uFbY,5188
13
13
  ato/hyperopt/hyperband.py,sha256=05qGvff0UAec4bTaaiCFa-FBRG0fIdVATaZu4vUiV5M,4233
14
- ato-2.0.2.dist-info/licenses/LICENSE,sha256=xrPRlaFeOLIYXHXJOsc7dhA2h1Jrcjw8t63M7OcVN6c,1071
15
- ato-2.0.2.dist-info/METADATA,sha256=QPyblQoGCgc79nDbpHRAC8c2lIsN88vyjRohP8LHWEQ,35566
16
- ato-2.0.2.dist-info/WHEEL,sha256=_zCd3N1l69ArxyTb8rzEoP9TpbYXkqRFSNOD5OuxnTs,91
17
- ato-2.0.2.dist-info/top_level.txt,sha256=Ea_cEtrnO1ir26dBT1CK_Mj6vK36sd9oSAu6WjtQkAU,4
18
- ato-2.0.2.dist-info/RECORD,,
14
+ ato-2.0.3.dist-info/licenses/LICENSE,sha256=xrPRlaFeOLIYXHXJOsc7dhA2h1Jrcjw8t63M7OcVN6c,1071
15
+ ato-2.0.3.dist-info/METADATA,sha256=676RCPgQwliZ2DTDxb91AIvR__jq_h2YFauwzSjwEWQ,37901
16
+ ato-2.0.3.dist-info/WHEEL,sha256=_zCd3N1l69ArxyTb8rzEoP9TpbYXkqRFSNOD5OuxnTs,91
17
+ ato-2.0.3.dist-info/top_level.txt,sha256=Ea_cEtrnO1ir26dBT1CK_Mj6vK36sd9oSAu6WjtQkAU,4
18
+ ato-2.0.3.dist-info/RECORD,,
File without changes