chore: update dependency lockfiles - #557
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe dependency lockfile updates package versions and hashes for Anthropic, Docling, AWS, Google authentication, Hugging Face, Milvus Lite, pydantic-settings, pypdf, sentence-transformers, setuptools, soupsieve, and Starlette. It adds Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 10✅ Passed checks (10 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@distribution/requirements-lock.txt`:
- Around line 1565-1567: Before pinning milvus-lite==3.2.0 in the dependency
lock, define and document the upgrade behavior for the persisted database used
by build/build.yaml: provide an export/import migration path for pre-3.0 files
or require users to create a fresh database. Ensure the upgrade guidance
explicitly addresses incompatibility with legacy .db files and prevents existing
databases from being used silently with Milvus Lite 3.2.0.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 25365f1d-3386-4e9b-829b-299ae7bfb53a
📒 Files selected for processing (1)
distribution/requirements-lock.txt
| milvus-lite==3.2.0 \ | ||
| --hash=sha256:d6735d7a5bcb14fed2cc9a42da84d7396fef0040a0f7c2d1cace9f2134925571 \ | ||
| --hash=sha256:f0f5656b033b1b5cbcfdfb8a9d676e52236338f102c8011d7bbf611afe512bb4 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -C4 --hidden -S \
'milvus|Milvus|milvus_lite|\.db' \
--glob '*.py' \
--glob '*.yaml' \
--glob '*.yml' \
--glob '*.toml' \
.Repository: opendatahub-io/ogx-distribution
Length of output: 4189
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '--- requirements-lock around milvus-lite ---\n'
sed -n '1545,1580p' distribution/requirements-lock.txt
printf '\n--- pyproject/requirements references to milvus-lite ---\n'
rg -n --hidden -S 'milvus-lite|milvuslite|milvus_lite|inline::milvus' --glob '*.txt' --glob '*.toml' --glob '*.py' --glob '*.yaml' --glob '*.yml' .Repository: opendatahub-io/ogx-distribution
Length of output: 260
🌐 Web query:
PyPI milvus-lite 3.2.0 rebuilt storage engine local db files migration database compatibility
💡 Result:
Database files (.db) created by versions of milvus-lite prior to 3.0.0 (the original C++/CGo-based storage format) are not compatible with milvus-lite version 3.0.0 and later, including version 3.2.0 [1][2][3]. The architecture was entirely rebuilt in pure Python, moving from the previous implementation to an LSM-style storage engine [2][4]. There is no automated migration path or tool for these legacy database files [1][5][2]. To migrate data to milvus-lite 3.2.0, you must: 1. Maintain access to the environment where the original milvus-lite (v2.x or earlier) is installed. 2. Use the compatibility dump command available in the older version to export your collections into a format such as Milvus BulkWriter JSON [1][2][6]. 3. Import that data into a new database created with the current milvus-lite 3.2.0 [1][2][3]. The dump command (milvus-lite dump) is designed to facilitate this process by exporting data that can then be ingested into Milvus servers or re-imported [5][6]. Always ensure you are working in a clean environment when upgrading or transitioning between these versions to avoid conflicts between the incompatible storage engines [1][7].
Citations:
- 1: https://pypi.org/project/milvus-lite/3.1.0/
- 2: https://github.com/milvus-io/milvus-lite/
- 3: chore: Upgrade milvus-lite to >=3.0.0 and remove pymilvus upper limit feast-dev/feast#6551
- 4: https://pypi.org/project/milvus-lite/3.1.1/
- 5: https://github.com/milvus-io/milvus-lite
- 6: https://milvus.io/docs/milvus_lite.md
- 7: https://github.com/milvus-io/milvus-lite?tab=readme-ov-file
🌐 Web query:
milvus-lite 3.2.0 release notes storage engine local .db files
💡 Result:
As of August 7, 2026, Milvus Lite has not released a version 3.2.0. The most recent versions available are v3.1.0 and v3.1.1 [1][2]. Regarding the storage engine and local.db files, there is a notable distinction in how Milvus Lite handles storage depending on the version and implementation architecture: 1. Current Pure-Python Architecture (v3.0.0 and later): The current generation of Milvus Lite, which was rewritten in pure Python, uses an LSM-style (Log-Structured Merge-tree) storage engine [3][4]. In this architecture, data is written to a Write-Ahead Log (WAL) and in-memory memtables, and flushed as immutable Parquet segments [3][4]. Vector indexes are persisted as separate.idx files, and the database state is managed by an atomic manifest [4]. 2. SQLite-Based Architecture: Some documentation describes a version of Milvus Lite that utilizes SQLite as its embedded storage backend for both collection metadata and vector/scalar data [5][6][7]. In this model, the.db file functions as a single persistent store [6]. Compatibility Note: Because the current pure-Python engine and older versions differ significantly in their storage formats,.db files created by earlier versions of Milvus Lite are generally not compatible with the newer pure-Python engine [4]. Users cannot perform an in-place migration; data must be re-imported into a new database [4]. For local usage, you can initialize the database using the MilvusClient: client = MilvusClient("./demo.db") [3][8] The.db file specified serves as the local database path [8]. While the API remains consistent across different Milvus deployments (Standalone, Distributed, and Zilliz Cloud), the underlying local storage implementation is optimized for lightweight, single-node prototyping and testing [3][4][8].
Citations:
- 1: https://pypi.org/project/milvus-lite/3.1.0/
- 2: https://pypi.org/project/milvus-lite/
- 3: https://github.com/milvus-io/milvus-lite?tab=readme-ov-file
- 4: https://github.com/milvus-io/milvus-lite
- 5: https://deepwiki.com/milvus-io/milvus-lite/3.7-storage-system
- 6: https://deepwiki.com/milvus-io/milvus-lite/3-system-architecture
- 7: https://deepwiki.com/milvus-io/milvus-lite/3.4-core-engine
- 8: https://milvus.io/docs/milvus_lite.md
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
sed -n '1545,1580p' distribution/requirements-lock.txt
printf '\n--- pyproject/requirements references to milvus-lite ---\n'
rg -n --hidden -S 'milvus-lite|milvuslite|milvus_lite|inline::milvus' --glob '*.txt' --glob '*.toml' --glob '*.py' --glob '*.yaml' --glob '*.yml' .
printf '\n--- tracked files mentioning milvus in names ---\n'
git ls-files | rg -i 'milvus'Repository: opendatahub-io/ogx-distribution
Length of output: 2800
Define the Milvus Lite storage upgrade path before pinning 3.2.0.
build/build.yaml persists the inline Milvus database at /opt/app-root/src/.ogx/distributions/rh/milvus.db. Milvus Lite 3.0 uses a rebuilt pure-Python storage engine, and .db files from pre-3.0 versions are incompatible; document migration via export/import or require a fresh database for upgrades. CWE-829 controls this dependency change; if legacy databases persist, this can cause data-access failures or corrupted read behavior.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@distribution/requirements-lock.txt` around lines 1565 - 1567, Before pinning
milvus-lite==3.2.0 in the dependency lock, define and document the upgrade
behavior for the persisted database used by build/build.yaml: provide an
export/import migration path for pre-3.0 files or require users to create a
fresh database. Ensure the upgrade guidance explicitly addresses incompatibility
with legacy .db files and prevents existing databases from being used silently
with Milvus Lite 3.2.0.
Sources: Path instructions, MCP tools
3d5ef7d to
7080c90
Compare
7080c90 to
d588f86
Compare
|
Tick the box to add this pull request to the merge queue (same as
|
|
@eoinfennessy: The following test has Succeeded: OCI Artifact Browser URLInspecting Test Artifacts ManuallyTo inspect your test artifacts manually, follow these steps:
mkdir -p oras-artifacts
cd oras-artifacts
oras pull quay.io/opendatahub/odh-ci-artifacts:ogx-core-functional-its-bzfp6 |
4 participants
Automated lockfile update
Warning
This PR is auto-generated. Do not request changes from the author - push
changes directly if necessary.
This PR regenerates the pinned dependency lockfiles to pick up upstream package changes.
Updated files
distribution/requirements-lock.txtSummary by CodeRabbit