Is it possible to place .cocoindex_code/settings.yml outside the target project directory?

[hahwul]

Hi cocoindex!
First of all, thank you so much for creating such a great tool :D

While using cocoindex-code, I have one question. Is it possible to configure or change the location of the .cocoindex_code/settings.yml file (which is currently created in the root of the target project) so that it can be managed in a separate directory?

The reason is that I’m using it for source code security analysis, so I’d prefer not to make any changes inside the target directory. I couldn’t find any information about this in the documentation. Did I miss something, or is there a hidden trick to achieve this?

Thanks in advance for your help!

[rudironsoni]

I opened #171 for this: #171

The short version is that you should be able to use CocoIndex Code against a repo without having to drop a .cocoindex_code/settings.yml file into that repo first.

In that PR, ccc init uses the built-in project defaults by default. It only writes <project>/.cocoindex_code/settings.yml if you explicitly ask for repo-local overrides with:

ccc init --project-settings

Same for .gitignore: we only touch it if ccc init --gitignore is passed.

The PR also moves the new Git-layer daemon state outside the checkout, under COCOINDEX_CODE_STATE_DIR / the XDG data dir. So for the security-analysis use case, the intended flow is:

• keep global/user config outside the target repo with COCOINDEX_CODE_DIR if needed
• keep daemon/layer state outside the target repo with COCOINDEX_CODE_STATE_DIR
• optionally keep DB files outside the target repo with COCOINDEX_CODE_DB_PATH_MAPPING
• run indexing/search against the repo without creating repo-local project settings

One caveat: if you need custom per-project include/exclude patterns or custom chunkers, those overrides are still represented as a project settings.yml today. What #171 changes is that this file is no longer required for the normal/default indexing path.

[hahwul]

@rudironsoni
Thank you for the detailed explanation!
I'll keep an eye on PR #171 and look forward to using it without modifying the target repo.

Thanks again :)