Skip to main content

codebase-memory-deployv

Install codebase-memory-mcp and index Odoo instances by parts inside containers following the Vauxoo layout:

/home/odoo/instance/odoo
/home/odoo/instance/extra_addons/*

This tool only runs inside such a container (or SSH session) as user odoo; it refuses to start when /home/odoo/instance/odoo/odoo-bin is missing. It always indexes the real instance path — never an rsync/copy — so later code references and edits target the right files.

Install

pip install codebase-memory-deployv

Usage

codebase-memory-deployv

That single command:

  1. Installs codebase-memory-mcp in the local environment when it is not available yet.

  2. Resolves a stable project name from ${MAIN_REPO_FULL_PATH}/variables.sh, or from ${MAIN_REPO_PATH}/variables.sh relative to --repo-path (PROJECT=${MAIN_APP}_${VERSION}, e.g. vauxoo_12.0), so each container/customer gets its own graph and every pass reuses the same --name. Both variables are exported by deployv and point at the one repo that owns MAIN_APP/VERSION; only when neither is set does it fall back to globbing extra_addons/*/variables.sh, which is ambiguous when several repos ship one.

  3. Picks the module list, in this order:

    • --modules-file given → the modules listed there (see below).
    • Database reachable through odoo-bin shell → only installed modules from ir.module.module (no test_* addon modules, keeping backend unit tests inside real modules), listed by list_installed_modules.py which is fed to the shell.
    • Neither → every addon module found on disk.
  4. Renders .cbmignore (Odoo core odoo/odoo complete + selected modules, dropping static/lib, static/tests, minified JS, caches and .git) in cumulative batches of 25 modules, running codebase-memory-mcp cli index_repository after each batch so memory-killed one-shot indexing is never a problem.

  5. Validates the graph scope: no test_* addon modules indexed, no missing and no extra module roots compared to the expected module list, and every indexed file carrying one of the configured extensions (SOURCE_GLOBS: .py .xml .js .rst .md .css .scss .csv) — anything else means .cbmignore did not apply. Counts per extension are logged, unexpected ones marked (!):

    extensions_configured=.css,.csv,.js,.md,.py,.rst,.scss,.xml
    extensions_indexed=5 files=12057
    extension .py      files=4949
    extension .xml     files=3276
    extension .json    files=39 (!)
    unexpected_extensions=1 files=39 (not in SOURCE_GLOBS: .json)
    

    Both checks read the graph with query_graph over its File nodes, not with search_code: that one greps the indexed files and hard-caps the scan at 500 matched lines whatever --limit says, which reports the tail of a real instance (Odoo 19 alone ships 533 manifests) as missing.

Options

--repo-path PATH    instance root to index (default: /home/odoo/instance)
--project NAME      graph name; default derives MAIN_APP_VERSION from variables.sh
--batch-size N      modules per cumulative indexing pass; 0 indexes one-shot (default: 25)
--mode MODE         auto (default), installed, or all
--modules-file PATH ir.module.module export listing the modules to index
--skip-install      do not install codebase-memory-mcp when missing
--skip-validate     do not validate graph scope after indexing

Indexing the modules installed in production

A local docker container only installs the modules of the main app, while production usually has more modules installed by hand. Export ir.module.module from production and pass the file, so the graph covers the same code production runs:

codebase-memory-deployv --modules-file modules_installed.csv

The file is an ir.module.module export, either a csv or one module name per line (# comments and blank lines are ignored):

name,state
sale,installed
purchase,uninstalled
  • With a state column (state/status), only the installed rows are used.
  • Without one, the file is assumed to be already filtered to the installed modules.
  • Column headers may be the technical names (name, state) or the exported labels (Technical Name, Status); a headerless file is read as name[,state].
  • Modules listed but missing on disk are reported as not_on_disk and skipped — they simply are not in this container's repos.

Development

tox -e py-multi   # tests in parallel
tox -e lint       # pre-commit checks
tox -e build      # release rehearsal (sdist+wheel, twine check, install smoke test)

CHANGES

v0.1.1

  • [REF] codebase-memory-deployv: read variables.sh the way pre-commit-vauxoo does
  • [FIX] codebase-memory-deployv: make the test suite pass on Windows
  • [ADD] codebase-memory-deployv: install codebase-memory-mcp and index Odoo instances by parts

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

codebase_memory_deployv-0.1.1.tar.gz (20.1 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

codebase_memory_deployv-0.1.1-py3-none-any.whl (14.4 kB view details)

Uploaded Python 3

File details

Details for the file codebase_memory_deployv-0.1.1.tar.gz.

File metadata

  • Download URL: codebase_memory_deployv-0.1.1.tar.gz
  • Upload date:
  • Size: 20.1 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/7.0.0 CPython/3.14.6

File hashes

Hashes for codebase_memory_deployv-0.1.1.tar.gz
Algorithm Hash digest
SHA256 dda8882488a7b9a6f2f5ee46501becc0e7e68bbd48a81c287f19b72801580c3f
MD5 334cb4cafcfffeed114bdf192d46061c
BLAKE2b-256 99945b9887fdf5468a8ac828ecd11e7ed37fc2d40ff8a0b406e7459edfe478ce

See more details on using hashes here.

File details

Details for the file codebase_memory_deployv-0.1.1-py3-none-any.whl.

File metadata

File hashes

Hashes for codebase_memory_deployv-0.1.1-py3-none-any.whl
Algorithm Hash digest
SHA256 dd9301f6919e19453e6d794a9a8753784a17771f8226ca47af3218ea04fe2f89
MD5 5122dc13528ce8290f44d81d045df2c8
BLAKE2b-256 fdd6d4c57678b5a4f47c36ecaf9851d454b355a2f7c170f4f4bd802fae3e4a1a

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page