Add Ladybug (successor to Kuzu) as a target

[prrao87]

Motivation and context

Kuzu was an open-source (MIT) licensed property graph database, but the project was archived in October 2025. This PR introduces Ladybug, which is a fork of Kuzu (and an identical API) as a target for users who may have wanted to use a locally running embedded graph database built for performance.

Ladybug is maintained by @adsharma and there is a lot more functionality planned for greater interoperability with the lakehouse ecosystem, so CocoIndex users can also benefit.

Breaking change?

No.

Description of the changes

This PR adds a new Ladybug target that is a drop‑in Kuzu replacement by reusing the same Cypher API server integration, plus Python spec/declaration definitions for users to access in CocoIndex.

High-level summary of changes

• Wires Ladybug into the expected target registration for CocoIndex
• Adds Ladybug target docs (new page + index/sidebar)
• Adds a small serialization test to ensure the new specs emit the expected engine shape. A regression in serialization (missing kind, wrong mapping fields, missing connection key) would surface only at runtime. The new tests added are a minimal guard that the new specs serialize into the exact shape the engine expects.
• Adds an opt‑in COCOINDEX_SKIP_UV=1 env variable switch in run_cargo_test.sh to keep Python env vars intact (if the local uv-managed Python doesn’t align with the version expected by the tests) when running cargo test.

Detailed list

• Added Ladybug Rust target (Identical to the Kuzu API server-based solution that existed previously) in ladybug.rs.
• Registered Ladybug target module in mod.rs.
• Registered Ladybug factory in registration.rs.
  • reqwest_client is moved into targets::kuzu::register, so we clone it to reuse the same client for Ladybug registration.
  • We should considering de-registering Kuzu and letting users know to use Ladybug
• Added Python target/declaration specs in _engine_builtin_specs.py.
• Added Ladybug doc page in ladybug.md (includes pip install real_ladybug note).
• Added Ladybug to targets index in index.md.
• Added Ladybug to docs sidebar in sidebars.ts.
• Added a note in Kuzu docs pointing to Ladybug in kuzu.md.
  • Ideally, we should remove these docs the codebase as Kuzu is no longer maintained - Ladybug is its true successor.
• Added Ladybug spec serialization tests in test_targets_specs.py.
• Added opt‑in skip of uv run for Rust tests via COCOINDEX_SKIP_UV=1 in run_cargo_test.sh.

To do

• Decide on a strategy to remove Kuzu from the codebase and communicate to the user base that Ladybug is the “new Kuzu” going forward.
• Recommendation: Announce to users on discord that Ladybug is like-for-like with Kuzu, and suggest removing Kuzu entirely from this code base.

[badmonster0]

thanks @prrao87 !! will get back on this shortly!

[georgeh0]

The implementation seems exactly the same as Kuzu's. We only need to keep one of them.

One way is to keep this new ladybug.rs, but add a new field target_name: str to Factory. We can pass in the name to the register() function with "Ladybug" or "Kuzu" separately. Then we get the same code working for both targets.

What do you think?

[adsharma]

Given its read-only status, in the next few months it would be dangerous to run Kuzu as security problems are discovered in its dependencies. I expect the usage to shift to one of its forks such as ladybug.

[prrao87]

I agree, this is why i strongly recommend removing Kuzu from the list and only using Ladybug in place of it (as Ladybug is identical to Kuzu but is maintained and being improved).

[georgeh0]

Makes sense! I think we can cleanup Kuzu (but leave its doc for now, with a single line to point to Ladybug; and also leave type aliases in code (e.g. KuzuConnection = LadybugConnection). Do you want to do this cleanup in this PR? (the history will look nicer as it'll clearly show ladybug modules coming from kuzu)

[prrao87]

@georgeh0 just so I'm clear, are you suggesting to update the Kuzu file and remove the new file ladybug.rs, so that the git history shows that Kuzu was updated to Ladybug? I can do that, just want to be sure I understood.

[georgeh0]

Hi @prrao87, I'm suggesting:

• Keep all the new Ladybug files, and remove all Rust code for kuzu (this will make Git detect it as a "file move", which leaves the Git history clean)
• In targets/_engine_builtin_specs.py‎, replace current Kuzu types with type aliases to Ladybug types
• For the doc kuzu.md, leave a single line to say it's replaced by Ladybug and point to there

(there's also Kuzu examples, should be migrated to ladybug too, but with the alias they won't be broken, so we can migrate it later)

[adsharma]

Thank you @prrao87!

[adsharma]

structured

[adsharma]

Given its read-only status, in the next few months it would be dangerous to run Kuzu as security problems are discovered in its dependencies. I expect the usage to shift to one of its forks such as ladybug.