You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To add a new PathSim toolbox (like `pathsim-chem`):
322
+
PathView supports two complementary ways to extend the block library: **runtime toolboxes** that the user installs from the UI at any time, and **build-time toolboxes** that are baked into the deployed bundle.
315
323
316
-
### 1. Add to requirements
324
+
### Runtime Toolboxes (default)
317
325
318
-
Edit `scripts/config/requirements-pyodide.txt`:
326
+
Users install toolboxes from the **Toolbox Manager** dialog without rebuilding the app. Three install sources are supported:
319
327
320
-
```txt
321
-
--pre
322
-
pathsim
323
-
pathsim-chem>=0.2rc2 # optional
324
-
pathsim-controls # optional - your new toolbox
325
-
```
326
-
327
-
The `# optional` comment means Pyodide will continue loading if this package fails to install.
328
-
329
-
### 2. Create toolbox config
328
+
-**PyPI** — install a published package via `micropip` (Pyodide) or `pip` (Flask backend)
329
+
-**URL** — load a wheel or sdist hosted anywhere
330
+
-**Inline** — paste / upload a `.py` module to register ad-hoc blocks for one session
Once installed, PathView introspects the module's `Block` (and optional `Event`) subclasses, registers them as new node types, and persists the selection to `localStorage` so it replays on reload. The user can disable individual blocks, override their category, name, shape, or `syncPorts` flag, and uninstall the toolbox at any time. Saving a `.pvm` file embeds the list of toolbox dependencies; opening one elsewhere prompts to install missing pieces.
332
333
333
-
```json
334
-
{
335
-
"$schema": "../schemas/blocks.schema.json",
336
-
"toolbox": "pathsim-controls",
337
-
"importPath": "pathsim_controls.blocks",
334
+
Implementation lives in `src/lib/toolbox/` (catalog, installer, register, persistence). The curated catalog of one-click installable toolboxes is in `catalog.ts`:
338
335
339
-
"categories": {
340
-
"Controls": [
341
-
"PIDController",
342
-
"StateEstimator"
343
-
]
336
+
```typescript
337
+
exportconst TOOLBOX_CATALOG:CatalogEntry[] = [
338
+
{
339
+
id: 'pathsim-chem',
340
+
displayName: 'pathsim-chem',
341
+
source: { type: 'pypi', pkg: 'pathsim-chem' },
342
+
importPath: 'pathsim_chem',
343
+
defaultCategory: 'Chemical',
344
+
preloaded: true// seeded into store on first launch
344
345
}
345
-
}
346
+
];
346
347
```
347
348
348
-
### 3. (Optional) Add events
349
+
To add an entry to the catalog: append a `CatalogEntry` to `TOOLBOX_CATALOG` and ship — no extraction step, no rebuild required for the user. Toolboxes outside the catalog still work via the manager's PyPI/URL/file inputs.
349
350
350
-
Create `scripts/config/pathsim-controls/events.json` if the toolbox has custom events.
351
+
For the toolbox-package contract (which Python conventions a toolbox must follow to be introspectable), see [**docs/toolbox-spec.md**](docs/toolbox-spec.md).
351
352
352
-
### 4. Run extraction and build
353
+
### Build-time Toolboxes (bundled into the deploy)
353
354
354
-
```bash
355
-
npm run extract
356
-
npm run build
357
-
```
355
+
For toolboxes that should be available without an install step (e.g. the core `pathsim` toolbox itself), block metadata is extracted at build time:
358
356
359
-
No code changes needed - the extraction script automatically discovers toolbox directories.
357
+
1. Add the package to `scripts/config/requirements-pyodide.txt` so Pyodide can install it.
358
+
2. Create `scripts/config/<toolbox-id>/blocks.json` (and optionally `events.json`) listing the categories and block class names.
359
+
3. Run `npm run extract` to regenerate the TypeScript registry under `src/lib/*/generated/`.
360
360
361
-
For the full toolbox integration reference (Python package contract, config schemas, extraction pipeline, generated output), see [**docs/toolbox-spec.md**](docs/toolbox-spec.md).
361
+
The build-time path is appropriate when a toolbox is part of the core deployment; for everything else prefer the runtime path, which avoids a redeploy.
0 commit comments