ragit 0.3.2 release

2025-03-01

It's mostly bug fixes, with a few new features.

Ragit had a first-ever contribution from someone other than me (baehyunsol). Huge thanks to robottwo!

Dependencies

• chrono: 0.4.39 -> 0.4.40
• flate2: 1.0.35 -> 1.1.0
• serde: 1.0.217 -> 1.0.218
• serde_json: 1.0.135 -> 1.0.139

ragit-server

Added 3 endpoints to ragit-server.

• /{user-name}/{repo-name}/cat-file/{uid}
• /user-list
• /repo-list/{user-name}

There's also been a huge refactoring. Now you can use ? operators in handlers, instead of directly returning Box::new(with_status(500)).

It's a step toward ragit-hub.

PR #10 Improve model configuration flexibility and fallback behavior

@robottwo

This MR enhances the model configuration system in ragit with two key improvements:

1. Custom model configuration sources - Adds support for loading model configurations from:

• RAGIT_MODEL_CONFIG environment variable
• ~/.config/ragit/models.json file
• Existing per-repository configuration

2. Automatic fallback to lowest-cost model - Ensures ragit always uses a valid model:

• When the default model is unavailable in the user's configuration
• Selects the lowest-cost model as a fallback
• Displays a warning message when fallback occurs

3. Override defaults using ~/.config/ragit/{api.json, search.json, build.json} when init'ing a new rag.

• Allows you to set different parameters as "standard" across the types of data you are working with

Benefits

• Users can maintain consistent model configurations and RAG settings across repositories
• Improves robustness by ensuring ragit always uses a valid model
• Provides clear feedback when fallback occurs

API keys are not copied to the models by default, which allows the user to share rag-indexed directories with other users, and those other users will use their own API keys (falling back to their ~/.config/ragit/models.json keys) rather than the API key of the user who created the RAG.

fix gh issue #8 and #9

If you run, interrupt and resume rag build a lot of times, you might end up with a broken knowledge-base. 0.3.2 tries to avoid such state by more robust clean-up process.

If you spawn multiple rag build at the same time, you might end up with a broken knowledge-base. The best solution is to add a write lock file, but we're not there yet. Instead, 0.3.2 makes rag check --recover smarter so that it can recover from such broken knowledge-base. rag check --recover runs silently, so you don't have to bother calling it manually!

tests

4 tests are added: models_init, orphan_process, server and write_lock.