chartbook.cli

`chartbook.cli`#

Module Contents#

Functions#

`add_command`	Declare a dependency on another pipeline by its ID, and pin its newest snapshot from the store.
`build`	Make everything current: run the build script, then render the site.
`catalog`	Manage the chartbook catalog.
`catalog_add`	Add pipeline directory(ies) to the catalog.
`catalog_disable`	Disable a pipeline in the catalog.
`catalog_enable`	Re-enable a previously disabled pipeline in the catalog.
`catalog_generate`	Render the global catalog’s site, into docs/ beside its chartbook.toml.
`catalog_init`	Initialize the global catalog at ~/.chartbook/chartbook.toml.
`catalog_open`	Open the global catalog’s site in your default browser.
`check`	Check a project’s metadata and paths; exit nonzero on any problem.
`config`	Configure the default catalog path for data loading.
`create_data_glimpses`	Create a data glimpses report for the project’s declared dataframes.
`data`	Data operations (get paths, docs).
`data_get_docs`	Print documentation content for a dataframe.
`data_get_docs_path`	Get the path to a dataframe’s documentation source.
`data_get_path`	Get the path to a dataframe’s parquet file.
`docs`	The documentation site: `generate` renders it, `open` opens it.
`docs_generate`	Render the documentation site, in OUTPUT_DIR (./docs by default).
`docs_open`	Open the generated site in your default browser.
`index_diff`	Say what changed between two builds, from their index.json files.
`index_group`	Read the index.json a build writes beside the site.
`init`	Initialize a new chartbook project from the cookiecutter template.
`install`	Install bundled resources: user-level by default, or into the current directory with –project.
`install_claude_skill`	Install the Claude Code skill that comes with this ChartBook.
`lineage_command`	Show where this pipeline’s data comes from: every snapshot upstream, and any gap.
`ls`	List catalog objects (pipelines, dataframes, charts).
`ls_charts`	List all charts across pipelines.
`ls_dataframes`	List all dataframes across pipelines.
`ls_pipelines`	List all pipelines.
`main`	chartbook CLI tool for generating documentation websites.
`path_command`	Print the path of an asset: this pipeline’s, or a pinned copy of another’s.
`pin`	Freeze what this pipeline depends on.
`publish`	Stage a pipeline’s publishable files into a directory.
`push`	Reserved: send a pipeline to a registry. Not yet supported.
`resolve_project_dir`	Resolve the project directory to an absolute path.
`restore_command`	Put this pipeline’s own assets back on disk, from its snapshots in the store.
`run_command`	Run a script in this pipeline: `build`, unless another is named.
`snapshot`	Declare this pipeline’s build ready for the pipelines that depend on it.
`store`	Look after the store: where pinned files and snapshots are kept.
`store_gc`	Remove from the store what nothing needs any more.
`store_info`	Say which store this machine uses, and what set it.
`store_verify`	Hash every object in the store again; exit nonzero if one has changed.
`trust`	Trust a pipeline’s folder, so that a build of it runs as your own.
`update`	Move pins forward to the newest snapshot of each dependency.

Data#

STORE_ONLY

API#

chartbook.cli.STORE_ONLY#: ‘(store only: not on this machine; the catalog shows its snapshots)’

chartbook.cli.add_command(pipeline, key, commit, project_dir)#

Declare a dependency on another pipeline by its ID, and pin its newest snapshot from the store.

Writes "PIPELINE" = {} under [dependencies] in this pipeline’s chartbook.toml, leaving the rest of the file as it is, then runs chartbook pin. The pipeline is read from its snapshots in the store alone: no folder of it here, and no clone. chartbook update moves the pin to a newer snapshot.

Examples: chartbook add acme/rates chartbook add acme/rates –as rates chartbook add acme/rates –commit 3f2a9c1

chartbook.cli.build(remake, upstream, **site)#

Make everything current: run the build script, then render the site.

The same as chartbook run followed by chartbook docs generate, and it takes the arguments of chartbook docs generate. In a catalog, the build script is run in each of the catalog’s pipelines before the catalog’s site is rendered.

With no build script in [scripts], there is nothing to run, and only the site is rendered.

Inside a build script, say chartbook docs generate. chartbook build there would run the script that called it; it renders the site and says so.

As chartbook run, it stops before the build when an asset marked keep = true is not on disk while the store has a version of it: chartbook restore puts it back, and –remake builds without it.

–upstream first builds and snapshots each pipeline this one depends on by path that has no snapshot to pin, as chartbook run --upstream does.

Examples: chartbook build -f chartbook build -f –project-dir …/rate_forecast chartbook build -f –upstream

chartbook.cli.catalog()[source]#: Manage the chartbook catalog.

chartbook.cli.catalog_add(paths, catalog_path, yes)#

Add pipeline directory(ies) to the catalog.

PATHS can be one or more directories containing a chartbook.toml file, or glob patterns that expand to such directories.

Examples::

chartbook catalog add /path/to/pipeline
chartbook catalog add /path/to/parent/*
chartbook catalog add /path/to/parent/* -y
chartbook catalog add ./proj1 ./proj2 ./proj3

chartbook.cli.catalog_disable(pipeline_id, catalog_path)#

Disable a pipeline in the catalog.

The pipeline entry is kept but skipped during builds. Re-enable with chartbook catalog enable.

chartbook.cli.catalog_enable(pipeline_id, catalog_path)#: Re-enable a previously disabled pipeline in the catalog.

chartbook.cli.catalog_generate(force_write, strict, clean, watch, watch_interval)#

Render the global catalog’s site, into docs/ beside its chartbook.toml.

The catalog is the one ~/.chartbook/settings.toml names, or else ~/.chartbook/chartbook.toml. chartbook catalog open opens the site.

The build is incremental. Its working files are kept next to the catalog (in _docs/), and the next build redoes only the pipelines whose files changed since: for most of a large catalog, most of the time, nothing. Nothing runs in between; it is a record on disk that the next build reads. –clean discards it and rebuilds everything. –watch keeps rebuilding as files change.

chartbook.cli.catalog_init(title)#

Initialize the global catalog at ~/.chartbook/chartbook.toml.

Creates a minimal catalog with an empty pipelines section. Use chartbook catalog add to add pipelines afterwards.

chartbook.cli.catalog_open()#: Open the global catalog’s site in your default browser.

chartbook.cli.check(project_dir, within_days, policy_path, skip_outputs)#

Check a project’s metadata and paths; exit nonzero on any problem.

Meant for CI. Works on a pipeline or a catalog and reports four things, each naming the chartbook.toml and field to edit:

fields the policy requires that are missing or empty
declared paths that point at files that do not exist
pipelines in [dependencies] that cannot be found where they are said to be, and training data they do not declare
dataframe licenses that are expired, or expire within –within days

Required fields come from the [policy] of the catalog or pipeline checked, or from –policy, which checks a pipeline against the catalog it is published to. With no policy anywhere, the default recommended fields are reported as warnings and do not fail the check.

Only metadata and paths are checked; no data file is opened.

Data files, charts and notebooks are things a pipeline builds, and are usually not in git. A CI job that has not run the pipeline will find them all missing; –skip-outputs leaves them out and checks the rest.

Examples: chartbook check chartbook check –within 90 chartbook check –policy …/catalog chartbook check –skip-outputs

chartbook.cli.config()#

Configure the default catalog path for data loading.

Sets the path to a catalog’s chartbook.toml in ~/.chartbook/settings.toml so that data.load() can find pipelines without an explicit catalog_path argument.

chartbook.cli.create_data_glimpses(no_samples, no_stats, output_dir, size_threshold, project_dir)#

Create a data glimpses report for the project’s declared dataframes.

This command reads chartbook.toml, takes every dataframe it declares, and creates a comprehensive data glimpse report in Markdown format. The list comes from the manifest alone, so it works the same whether the project is built with doit, Snakemake, Make or plain scripts. Declared dataframes whose files do not exist yet are skipped.

The report is data_glimpses.md in –output-dir, which is made if it does not exist. An –output-dir ending in .md is the report’s own path.

Example usage: chartbook create-data-glimpses chartbook create-data-glimpses –no-samples chartbook create-data-glimpses –no-samples –no-stats chartbook create-data-glimpses -o ./docs/ chartbook create-data-glimpses –size-threshold 100

chartbook.cli.data()#: Data operations (get paths, docs).

chartbook.cli.data_get_docs(pipeline, dataframe, catalog)#

Print documentation content for a dataframe.

Examples: chartbook data get-docs –pipeline yield_curve –dataframe repo_public

chartbook.cli.data_get_docs_path(pipeline, dataframe, catalog)#

Get the path to a dataframe’s documentation source.

Examples: chartbook data get-docs-path –pipeline yield_curve –dataframe repo_public

chartbook.cli.data_get_path(pipeline, dataframe, catalog)#

Get the path to a dataframe’s parquet file.

Examples: chartbook data get-path –pipeline yield_curve –dataframe repo_public

chartbook.cli.docs()[source]#

The documentation site: generate renders it, open opens it.

chartbook docs generate renders the site from what the project has built and writes index.json beside it. chartbook docs open opens the rendered site in your browser. Neither builds the project’s data: chartbook run does that, and chartbook build runs the build script and then generates the site.

chartbook.cli.docs_generate(**site)#

Render the documentation site, in OUTPUT_DIR (./docs by default).

This renders the site and writes index.json beside it. It does not build the project’s data: chartbook run does that, and chartbook build does both. A lone pipeline that has built none of its data, charts, notebooks and models yet, as a new project has not, is rendered with a warning and each shown as not built; with –strict typed, and in a catalog, that is an error.

By default every render starts from nothing. With –incremental the intermediate build directory (–docs-build-dir) is kept, pipelines whose files have not changed are not regenerated, and only pages that differ are rendered again. –watch does that in a loop: render, then again each time a file changes. Open the site with chartbook docs open and refresh.

Examples: chartbook docs generate -f chartbook docs generate -f –incremental chartbook docs generate -f –watch

chartbook.cli.docs_open(output_dir, project_dir)#

Open the generated site in your default browser.

Looks for index.html in OUTPUT_DIR (./docs by default) and opens it with the system’s default web browser, on macOS, Windows and Linux.

Examples: chartbook docs open chartbook docs open ./my-docs chartbook docs open –project-dir /path/to/project

chartbook.cli.index_diff(before, after, as_json, exit_code)#

Say what changed between two builds, from their index.json files.

BEFORE and AFTER are two index.json files, or the folders that hold them (the site folder, docs/). Records are matched by kind and ID; the two are compared as published, so a build directory’s index and the site’s compare as equals, and generated_at is ignored.

Examples: chartbook index diff docs-main/ docs/ chartbook index diff old.json docs/index.json –exit-code

chartbook.cli.index_group()#: Read the index.json a build writes beside the site.

chartbook.cli.init(use_git, use_github, public)#

Initialize a new chartbook project from the cookiecutter template.

The template is the one that came with this ChartBook (the template/ folder of ChartBook’s repository, which the package carries), so the two always match, and rendering it needs no network. When the commit the template is at is known, the new project’s .cruft.json names the template on GitHub and that commit, so cruft update there brings in later changes to it; when it is not, there is no .cruft.json, and the command prints the cruft link that makes one.

With –git, the new project is also made a git repository with one commit. With –github, a GitHub repository is then created for it under the account gh is logged in as, and the commit is pushed. Both are off by default.

–github needs the GitHub CLI installed and logged in (gh auth login). That is checked first, so if it is missing nothing is created.

Examples: chartbook init chartbook init –git chartbook init –github chartbook init –github –public

chartbook.cli.install()[source]#: Install bundled resources: user-level by default, or into the current directory with –project.

chartbook.cli.install_claude_skill(force, project)#

Install the Claude Code skill that comes with this ChartBook.

By default the skill is installed user-level, into ~/.claude/skills/chartbook/, or $CLAUDE_CONFIG_DIR/skills/chartbook/ when that variable is set, so it is available in every Claude Code session. With –project it is installed into ./.claude/skills/chartbook/ in the current directory instead.

The skill’s SKILL.md names the ChartBook version it was written for. A copy for an older version is replaced, and the command says which version it replaced. A copy for a newer version, or for this version with files changed by hand, is replaced when you say so, or with –force. When the files already match, nothing is copied. Files of older layouts are removed, so the copy mirrors the bundled skill.

Any other command, run at a terminal, says in one line when your copy or the project’s is for an older ChartBook, and chartbook check warns.

Examples: chartbook install claude-skill chartbook install claude-skill –project

chartbook.cli.lineage_command(project_dir, check, rehash, as_json)#

Show where this pipeline’s data comes from: every snapshot upstream, and any gap.

Follows the pins up from this pipeline’s lockfile: each snapshot it is pinned to, the snapshots those were pinned to, and so on. Each step is checked: the snapshot is in the store, what was pinned is what it holds (by hash), and its recorded pins cover every dependency its own manifest declares. Nothing is written.

Examples: chartbook lineage chartbook lineage –check chartbook lineage –rehash –json

chartbook.cli.ls(ctx, catalog)#

List catalog objects (pipelines, dataframes, charts).

Without a subcommand, lists all objects in a tree format. Use subcommands to list specific object types.

Examples: chartbook ls chartbook ls pipelines chartbook ls dataframes chartbook ls charts

chartbook.cli.ls_charts(ctx)#: List all charts across pipelines.

chartbook.cli.ls_dataframes(ctx)#: List all dataframes across pipelines.

chartbook.cli.ls_pipelines(ctx)#: List all pipelines.

chartbook.cli.main(ctx)[source]#: chartbook CLI tool for generating documentation websites.

chartbook.cli.path_command(ref, kind, project_dir)#

Print the path of an asset: this pipeline’s, or a pinned copy of another’s.

REF names an asset declared in the enclosing chartbook.toml. A dataframe is named by its key alone; anything else has its kind in front:

treasury_rates [dataframes.treasury_rates] chart/yield_curve [charts.yield_curve] notebook/analysis [notebooks.analysis] note/methodology [notes.methodology] model/rate_forecaster [models.rate_forecaster]

The path is printed absolute, whether or not the file exists yet, so a build tool can use it for inputs and outputs alike. This is chartbook.assets.path() for Make, shell, R and Stata:

MERGED := $(shell chartbook path merged_rates)

An undeclared name fails, naming the table to add.

An asset of another pipeline has that pipeline in front:

fed_yield_curve:treasury_rates fed_yield_curve:chart/curve_today

The pipeline must be in [dependencies], and what is printed is the path of the copy that chartbook.lock pins, in the store: not the other pipeline’s own directory. Run chartbook pin first. That copy stays as it is until chartbook update.

Examples: chartbook path repo_public chartbook path chart/repo_rates chartbook path repo_rates –kind chart –project-dir …/yield_curve chartbook path fed_yield_curve:treasury_rates

chartbook.cli.pin(project_dir, frozen)#

Freeze what this pipeline depends on.

Each pipeline in [dependencies] is pinned to a snapshot of it: what its owner declared ready, at a commit (chartbook snapshot). The content hash of each of its assets is written to chartbook.lock. Commit that file: a change to what the project depends on then shows in a diff.

None of the other pipeline’s data in its folder is read. It can be half-way through a change, and what you pin is still the build that was declared ready. Its chartbook.toml and chartbook.lock are read, to see that the pin makes no cycle: a pin whose new or moved entries would lead back to this pipeline, or into pipelines that depend on each other, is not written.

A pin that already exists is never moved, whatever the other pipeline has done since; chartbook update moves pins. What pin does do again is pin a dependency that has no pin yet.

A dependency that is a git repository is fetched, and pinned from a clean copy of the commit.

–frozen pins nothing and writes nothing but, where the store can be written, its note that this machine reads these pins, so that store gc on another machine keeps them: not the lockfile, no object. It says whether the pipeline can be built from its lockfile alone, every dependency pinned and every pin in the store, and exits 1 if not. For CI, and for a store you may only read.

Examples: chartbook pin chartbook pin –project-dir …/rate_forecast chartbook pin –frozen

chartbook.cli.publish(publish_dir: pathlib.Path | str | None, project_dir: pathlib.Path | str, verbose: bool)#

Stage a pipeline’s publishable files into a directory.

If no publish directory is provided, a default local directory will be used.

Publishing copies files and does nothing else: no network, no registry. Sending a pipeline to a registry is a different act with a different verb, chartbook push, which is reserved and not yet implemented.

chartbook.cli.push()#

Reserved: send a pipeline to a registry. Not yet supported.

publish already means “stage files into a directory”, so the registry gets its own verb rather than a second meaning for that one. The name is claimed here so that nothing else takes it first.

chartbook.cli.resolve_project_dir(project_dir: pathlib.Path | None)[source]#

Resolve the project directory to an absolute path.

Parameters:: project_dir (Path, optional) – The project directory path, or None to use cwd.
Returns:: The resolved absolute path to the project directory.
Return type:: Path

chartbook.cli.restore_command(names, project_dir)#

Put this pipeline’s own assets back on disk, from its snapshots in the store.

With no NAMES, every asset chartbook.toml marks keep = true that is not on disk: a costly output, after a clean or in a fresh clone. Name assets to put those back, kept or not, as chartbook path names them: embeddings, model/forecaster, chart/curve.

Each comes from the newest snapshot of this pipeline that holds it, with its bytes in the store, and is written at the path the manifest declares now; the command says which commit and date it came from. Nothing on disk is written over: an asset that is there is left, and said. This is the mirror of chartbook snapshot, which copies the folder into the store. Whether your build tool then skips the step that makes the asset is its own rule; the guide on keeping costly outputs has the recipe for doit.

Exits 1 if an asset named could not be put back. With no NAMES, a kept asset that is missing and that no snapshot holds yet (a first build) is said, and the command exits 0, so that CI may run it before every build. The snapshots are found through the commits the clone has: a shallow clone (CI’s fetch-depth: 1) sees none of them.

Examples: chartbook restore chartbook restore embeddings chartbook restore model/forecaster chart/curve

chartbook.cli.run_command(script, project_dir, force, make_snapshot, frozen, remake, upstream)#

Run a script in this pipeline: build, unless another is named.

SCRIPT is a name from [scripts] in chartbook.toml.

[scripts] build = “doit” test = “pytest”

build is the script that makes a pipeline’s data current. Before it runs, whatever this pipeline depends on and has not pinned yet is pinned, so its code can read it. A pin that exists is never moved: you are told what has changed, and chartbook update moves pins.

It never builds in a folder this pipeline depends on, unless you say –upstream (below). That folder is somebody’s work, and this pipeline reads what is pinned, not what is there.

A dependency that is a git repository is built once, in ChartBook’s own clean copy of the commit, so that what it builds can be pinned. –force builds it again, which is how data it pulls from outside is refreshed.

In a catalog, the script is run in each of the catalog’s pipelines.

–snapshot builds and then declares the build ready, in one command. It is chartbook run followed by chartbook snapshot, with two differences: it checks that everything is committed before it builds, and the snapshot records that the build ran in the same command.

Examples: chartbook run chartbook run test chartbook run –force chartbook run –snapshot chartbook run –frozen chartbook run –upstream

–frozen pins nothing and writes nothing before the build but, where the store can be written, its note that this machine reads these pins: not the lockfile, no object, and no git dependency is fetched or built. The build runs only if the lockfile is complete and every pin is in the store (chartbook pin --frozen says the same without building). For CI, and for a store you may only read.

An asset chartbook.toml marks keep = true cost something to make. If one is not on disk while the store has a version of it, build stops before anything runs and says so: chartbook restore puts it back, and –remake runs the build without it, which makes it again.

–upstream is for folders that are yours. A pipeline this one depends on by path, on this machine, that has no snapshot to pin and is not pinned yet is built first, and snapshotted once its build succeeds, so that this one can pin it; its own the same way, each before what depends on it. Each must be trusted to run, have a build script and have everything committed, and its build must leave it so. The first that fails stops the run.

chartbook.cli.snapshot(project_dir, deep)#

Declare this pipeline’s build ready for the pipelines that depend on it.

Every asset the pipeline declares and has built is copied into the store, labelled with the commit the pipeline is at. That is a snapshot, and it is what other pipelines pin: they never read this folder. With the bytes go the pipeline’s own index at that commit and the files a site needs (the manifest, the README, the write-ups, the site pages), only those git tracks, so a version’s site can be built from the store.

Everything in the pipeline’s folder must be committed first. The label says “this is what that commit built”, and with uncommitted changes it would not be true. What git ignores, such as built data, does not count.

A snapshot is made when you ask for one, not by every build. Until you make another, pipelines that depend on this one keep getting this one, however much you change here. When you do, they get it with chartbook update, and not before.

Build first: this does not run the build. chartbook run does.

Examples: chartbook run && chartbook snapshot chartbook snapshot –project-dir …/fed_yield_curve

chartbook.cli.store()#

Look after the store: where pinned files and snapshots are kept.

The store keeps files under the hash of what is in them. It is a folder on this machine, or one machines share (on a shared disk, or synced by a service such as Google Drive), or a bucket. It is ~/.chartbook/store unless CHARTBOOK_STORE, or [store] url in ~/.chartbook/settings.toml or in the organization’s settings file (/etc/chartbook/settings.toml, or what CHARTBOOK_SYSTEM_SETTINGS names), says otherwise. chartbook store info says which it is.

chartbook.cli.store_gc(dry_run, yes, forget_missing, keep_days, keep_lineage, aggressive)#

Remove from the store what nothing needs any more.

The store is shared by every project of yours. Two things keep what is in it. A lockfile: each chartbook pin and chartbook update notes its lockfile here, and every object one of them names is kept. And a snapshot: what chartbook snapshot kept of a pipeline at a commit.

A snapshot is kept if a lockfile pins it, if a lockfile pins a model version by its label and this is the newest snapshot holding that version, if it is the newest of its pipeline from its repository or the newest a branch or tag can pin from, if it says which repository the kept snapshots are of, if a label points at a model version in it (in that pipeline’s chartbook.toml, or as its newest snapshot recorded), if it is the newest holding a version of an asset marked keep = true (every version of such an asset is kept, –aggressive or not, and the command says what the marks keep), or if it was made in the last 7 days (–keep-days). Otherwise it may be removed, and what only it named goes with it. A store keeps what work needs now, and lets old lineage go: with –keep-lineage, every snapshot a kept snapshot was made from is kept too, as far up as it goes, for chartbook lineage to check. With –aggressive, names keep nothing: a snapshot a git tag or branch names, or one holding a labelled model version that no lockfile pins, goes once nothing else keeps it.

A lockfile that cannot be found, because its project was deleted or its drive is not plugged in, still keeps what it last pinned. Pass –forget-missing to let those go. A note only ever adds to what is kept: what a lockfile’s note recorded at its last pin is kept even when the lockfile here says otherwise now. A note of a lockfile on another machine, which a store in a shared or synced folder has, is kept with –forget-missing or without, as is a note from before notes named their machine and a sync service’s copy of a note; each is listed with its file under roots/, which you remove once no machine needs it. In your own store, under ~/.chartbook, a note from before notes named their machine is this machine’s: its lockfile is read, and the note is removed once this machine has a note of that lockfile and the lockfile is read here, or with –forget-missing once the lockfile is gone.

What would be removed is listed, and nothing is removed until you say yes. An object stored in the last hour is never removed: a pin puts files in the store before it writes the lockfile that names them. In a store users share, what another user put there may be theirs alone to remove: gc removes what it can, says what it removed, lists each thing it could not remove with what to do, and exits 1.

Examples: chartbook store gc –dry-run chartbook store gc chartbook store gc –keep-days 7 chartbook store gc –yes –forget-missing chartbook store gc –keep-lineage chartbook store gc –aggressive –keep-days 0

chartbook.cli.store_info()#

Say which store this machine uses, and what set it.

The store is a setting of the machine, read in layers: CHARTBOOK_STORE, then [store] url in your settings file, then in the organization’s, then the default. On a machine that is to share a store with another, this is what to check first.

Examples: chartbook store info CHARTBOOK_STORE=/shared/store chartbook store info

chartbook.cli.store_verify()#

Hash every object in the store again; exit nonzero if one has changed.

An object’s name is the hash of its content, so this finds whatever has changed since it was stored: a file the store hard-linked or symlinked to that has since been rewritten, a link whose file has gone, or anything edited in the store by hand. Every byte is read, so on a large store it takes a while.

Examples: chartbook store verify CHARTBOOK_STORE=/shared/store chartbook store verify

chartbook.cli.trust(path, render_only, repository, members, list_, forget)#

Trust a pipeline’s folder, so that a build of it runs as your own.

A build of a folder you have not trusted runs as a build of files from a store does: chartbook docs generate renders its site with no query run and no template or file from outside the folder, and chartbook build and chartbook run refuse to run its build script, which is code. A project chartbook init made is trusted as it is made. One you cloned is trusted when you say so, here.

With no PATH, this folder. A folder’s trust covers the folders inside it, so chartbook trust ~/GitRepositories/ftsfr trusts every pipeline under it. –repository trusts the folder’s origin repository instead: every clone of it, wherever it is. –members, in a catalog, trusts the catalog’s folder and each of its member folders on this machine.

Two levels. run, the default, lets the build script run. –render lets queries run and the files the manifest names be read, wherever they are, and no more. The record is ~/.chartbook/trust.toml, yours; –list shows it, and –forget takes a folder (or, with –repository, a repository) out of it. Under CI (the environment variable) the checkout is trusted to run without a record, and CHARTBOOK_TRUST=all trusts every folder.

Examples: chartbook trust chartbook trust –render chartbook trust …/rates chartbook trust –repository chartbook trust –members chartbook trust –list chartbook trust –forget

chartbook.cli.update(dependencies, project_dir)#

Move pins forward to the newest snapshot of each dependency.

With no argument, every dependency is updated. Name some to update only those, as they are written in [dependencies]; the scope may be left off when only one has that name. Each pin that changes is printed with its old and new hash, and chartbook.lock is rewritten.

Nothing is rebuilt: this pipeline’s own outputs are as they were.

Examples: chartbook update chartbook update fed_yield_curve