Context
PR #653 added per-chunk SSE progress and surfaced it in the web Index tab. The mm init wizard's seed-index path (packages/memtomem/src/memtomem/cli/init_cmd.py:_seed_with_progress, line 1496-) consumes the same index_path_stream but ignores the new chunk_progress events. PR #653 left this out deliberately — see PR description "Out of scope" and the docstring note in the code.
Why this needs design
_seed_with_progress uses click.progressbar configured for file-unit length with this item_show_func:
click.progressbar(
length=expected_total, # files
label=" Seeding",
item_show_func=lambda item: (item or "").rsplit("/", 1)[-1][:40],
)
Two problems:
- The
item_show_func extracts the path tail and truncates to 40 chars. Passing a free-form "file (32/250)" works for "/"-less inputs but the chunk count gets eaten by the truncate.
- The bar's length is in files, so
chunk_progress events have no natural advance unit. Just calling bar.update(0, label) works (advance=0, label refresh) but the wizard's UX tone is "minimal CLI noise" — fast-firing chunk labels may feel busy.
Options
- Refresh sub-label without advance —
bar.update(0, f"{file} {done}/{total}") and a wider item_show_func that handles both formats. Simplest. Risk: noisy on fast files.
- Switch bar length to chunk units —
length=expected_chunks instead of expected_total files; advance per chunk. Requires pre-counting chunks (currently only files are pre-counted). Cost-heavy.
- Two-bar layout — outer file-bar, inner per-file chunk-bar shown only when
chunks_total > N. Most informative but click.progressbar doesn't compose well.
Acceptance criteria
- Wizard seed run shows chunk-level progress for files producing more than
progress_threshold chunks (default 32).
- Small files (under threshold) stay quiet — match the web Index tab behavior.
- KeyboardInterrupt cleanup still works (test: ^C mid-seed prints the resume hint,
_close_bar runs).
- No regression in the multi-path aggregation summary line at the end.
Files likely touched
References
Context
PR #653 added per-chunk SSE progress and surfaced it in the web Index tab. The
mm initwizard's seed-index path (packages/memtomem/src/memtomem/cli/init_cmd.py:_seed_with_progress, line 1496-) consumes the sameindex_path_streambut ignores the newchunk_progressevents. PR #653 left this out deliberately — see PR description "Out of scope" and the docstring note in the code.Why this needs design
_seed_with_progressusesclick.progressbarconfigured for file-unit length with thisitem_show_func:Two problems:
item_show_funcextracts the path tail and truncates to 40 chars. Passing a free-form"file (32/250)"works for "/"-less inputs but the chunk count gets eaten by the truncate.chunk_progressevents have no natural advance unit. Just callingbar.update(0, label)works (advance=0, label refresh) but the wizard's UX tone is "minimal CLI noise" — fast-firing chunk labels may feel busy.Options
bar.update(0, f"{file} {done}/{total}")and a wideritem_show_functhat handles both formats. Simplest. Risk: noisy on fast files.length=expected_chunksinstead ofexpected_totalfiles; advance per chunk. Requires pre-counting chunks (currently only files are pre-counted). Cost-heavy.chunks_total > N. Most informative butclick.progressbardoesn't compose well.Acceptance criteria
progress_thresholdchunks (default 32)._close_barruns).Files likely touched
packages/memtomem/src/memtomem/cli/init_cmd.py(_seed_with_progress)packages/memtomem/src/memtomem/cli/indexing.pyifmm index(non-stream) is folded in at the same time — see feat(cli): convert mm index to stream + click.progressbar #656 for the related conversion.References