Establish workspace with core, data, and cli crates#1
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @leynos, you have reached your 24-hour rate limit for Sourcery. Please try again later
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Warning Rate limit exceeded@leynos has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 8 minutes and 22 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (8)
Summary by CodeRabbit
WalkthroughCreate a Rust workspace with members Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev
participant GH as GitHub Actions
participant Toolchain as actions-rs/toolchain
participant Cache as rust-cache
participant Make as make
Dev->>GH: push / pull_request
GH->>Toolchain: install nightly + rustfmt + clippy + llvm-tools (override)
GH->>Cache: restore cargo cache
GH->>Make: make check-fmt
GH->>Make: make markdownlint
GH->>Make: make nixie
GH->>Make: make lint
GH->>Make: make test
Make-->>Cache: save caches
sequenceDiagram
autonumber
actor User
participant CLI as wildside (wildside-cli)
User->>CLI: run
CLI-->>User: exit (no-op)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🔭 Outside diff range comments (1)
Cargo.toml (1)
15-49: Relax float_arithmetic to reduce friction for numerics-heavy codeDenying all floating-point arithmetic at workspace level will block legitimate domain logic (distances, scores, travel times). Gate exceptions locally or start with a warning.
Apply this diff:
# 6. numerical foot-guns -float_arithmetic = "deny" +float_arithmetic = "warn"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- Jira integration is disabled
You can enable these settings in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (8)
Cargo.toml(1 hunks)cli/Cargo.toml(1 hunks)cli/src/main.rs(1 hunks)core/Cargo.toml(1 hunks)core/src/lib.rs(1 hunks)data/Cargo.toml(1 hunks)data/src/lib.rs(1 hunks)docs/roadmap.md(2 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.rs
⚙️ CodeRabbit Configuration File
**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.
Adhere to single responsibility and CQRS
Place function attributes after doc comments.
Do not use
returnin single-line functions.Move conditionals with >2 branches into a predicate function.
Avoid
unsafeunless absolutely necessary.Every module must begin with a
//!doc comment that explains the module's purpose and utility.Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar
Lints must not be silenced except as a last resort.
#[allow]is forbidden.- Only narrowly scoped
#[expect(lint, reason = "...")]is allowed.- No lint groups, no blanket or file-wide suppression.
- Include
FIXME:with link if a fix is expected.Where code is only used by specific features, it must be conditionally compiled or a conditional expectation for unused_code applied.
Use
rstestfixtures for shared setup and to avoid repetition between tests.Replace duplicated tests with
#[rstest(...)]parameterised cases.Prefer
mockallfor mocks/stubs.Prefer
.expect()over.unwrap()Ensure that any API or behavioural changes are reflected in the documentation in
docs/Ensure that any completed roadmap steps are recorded in the appropriate roadmap in
docs/Files must not exceed 400 lines in length
- Large modules must be decomposed
- Long match statements or dispatch tables should be decomposed by domain and collocated with targets
- Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.
Files:
data/src/lib.rscore/src/lib.rscli/src/main.rs
**/*.md
⚙️ CodeRabbit Configuration File
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/roadmap.md
🔇 Additional comments (3)
data/src/lib.rs (1)
1-1: LGTM: Module-level docs are present and correctly use//!.The crate header satisfies the guideline requiring a module doc comment at the start of every module.
core/src/lib.rs (1)
1-1: LGTM: Module-level docs are present and correctly use//!.The crate header meets the documentation and style requirements.
docs/roadmap.md (1)
29-29: LGTM: Markdownlint suppression placementThe MD013 suppression is correctly scoped to the following long line.
There was a problem hiding this comment.
Actionable comments posted: 8
🔭 Outside diff range comments (4)
wildside-core/Cargo.toml (1)
7-8: Remove the empty [dependencies] section.Trim the manifest noise until you actually add a dependency.
Apply this diff:
-[dependencies] -wildside-core/src/lib.rs (1)
1-2: Tighten crate guarantees and expand the crate-level docs.Enforce no-unsafe at the crate level and flesh out the module docs to meet the “purpose and utility” guideline. Keep crate attributes after the inner doc comment.
Apply this diff:
//! Core domain types for the Wildside engine. +#![forbid(unsafe_code)] +#![deny(missing_docs)] +//! +//! This crate defines the canonical data structures and invariants shared across +//! the Wildside workspace. Keep this crate free of I/O, async runtimes, and +//! third-party dependencies to maximize reuse. +//! +//! Responsibilities: +//! - Domain value objects and identifiers +//! - Pure business rules and validation predicates +//! - Error types shared between crates +//! +//! Non-goals: +//! - Persistence (see wildside-data) +//! - CLI or UX concerns (see wildside-cli) +//! +//! Examples +//! ```ignore +//! // When types are added, include a minimal usage example here. +//! ```wildside-data/Cargo.toml (1)
7-8: Remove the empty [dependencies] section.Avoid empty tables until needed.
Apply this diff:
-[dependencies] -Cargo.toml (1)
20-54: Align Clippy policy with repository guidelines and planned float usage.
- The guideline states “Prefer .expect() over .unwrap()”. Denying expect_used contradicts that. Deny unwrap_used, but allow or warn on expect_used.
- The roadmap specifies scoring APIs using f32. Denying float_arithmetic at the workspace level will block core/data/scorer logic. Relax at workspace level; enforce narrowly with #[expect(..., reason = "...")] where genuinely required.
Apply this diff:
[workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } @@ # 3. panic-prone operations unwrap_used = "deny" -expect_used = "deny" +expect_used = "warn" @@ # 6. numerical foot-guns -float_arithmetic = "deny" +float_arithmetic = "warn"Optionally, document in CONTRIBUTING.md that .expect(...) must include a clear, actionable failure message, and use narrowly-scoped #[expect(..., reason = "...")] only with a FIXME link when suppressing.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- Jira integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (9)
.github/workflows/ci.yml(1 hunks)Cargo.toml(1 hunks)docs/roadmap.md(10 hunks)wildside-cli/Cargo.toml(1 hunks)wildside-cli/src/main.rs(1 hunks)wildside-core/Cargo.toml(1 hunks)wildside-core/src/lib.rs(1 hunks)wildside-data/Cargo.toml(1 hunks)wildside-data/src/lib.rs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.rs
⚙️ CodeRabbit Configuration File
**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.
Adhere to single responsibility and CQRS
Place function attributes after doc comments.
Do not use
returnin single-line functions.Move conditionals with >2 branches into a predicate function.
Avoid
unsafeunless absolutely necessary.Every module must begin with a
//!doc comment that explains the module's purpose and utility.Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar
Lints must not be silenced except as a last resort.
#[allow]is forbidden.- Only narrowly scoped
#[expect(lint, reason = "...")]is allowed.- No lint groups, no blanket or file-wide suppression.
- Include
FIXME:with link if a fix is expected.Where code is only used by specific features, it must be conditionally compiled or a conditional expectation for unused_code applied.
Use
rstestfixtures for shared setup and to avoid repetition between tests.Replace duplicated tests with
#[rstest(...)]parameterised cases.Prefer
mockallfor mocks/stubs.Prefer
.expect()over.unwrap()Ensure that any API or behavioural changes are reflected in the documentation in
docs/Ensure that any completed roadmap steps are recorded in the appropriate roadmap in
docs/Files must not exceed 400 lines in length
- Large modules must be decomposed
- Long match statements or dispatch tables should be decomposed by domain and collocated with targets
- Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.
Files:
wildside-data/src/lib.rswildside-core/src/lib.rswildside-cli/src/main.rs
**/*.md
⚙️ CodeRabbit Configuration File
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/roadmap.md
🪛 actionlint (1.7.7)
.github/workflows/ci.yml
13-13: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 LanguageTool
docs/roadmap.md
[locale-violation] ~163-~163: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...ing and Versioning** - [ ] Add the ISC LICENSE file to the root of the workspace and ...
(LICENCE_LICENSE_NOUN_SINGULAR)
🔇 Additional comments (9)
wildside-core/Cargo.toml (1)
1-6: LGTM: Workspace-inherited edition and non-publishable core crate are set correctly.The manifest is minimal and aligned with a dependency-light core crate.
wildside-data/Cargo.toml (1)
1-6: LGTM: Data crate scaffold matches the workspace conventions.The package section is clean and inherits the edition correctly.
wildside-cli/Cargo.toml (1)
9-11: LGTM: Binary target mapping is correct.The bin name and path are coherent with the crate intent.
wildside-data/src/lib.rs (1)
1-14: LGTM on module docs and boundaries.Start the module with
//!docs, scope responsibilities clearly, and call out async and domain boundaries. This matches the workspace documentation standard..github/workflows/ci.yml (1)
21-24: Remove suggestion: CI lint and test targets already enforce warnings as errorsThe Makefile defines
CLIPPY_FLAGSwith-D warningsfor the lint target and appliesRUSTFLAGS="-D warnings"to the test target, so the CI pipeline already fails on warnings.Cargo.toml (1)
9-11: LGTM on workspace resolver and centralised edition.Pin resolver = "2" and centralise edition under [workspace.package]; this keeps member manifests tidy.
docs/roadmap.md (3)
48-49: LGTM on Oxford -ize usage in technical prose.Standardize with -ize aligns with the en-GB-oxendict rule set used across the repo.
99-104: LGTM on API relocation notes.Anchor SolveRequest/SolveResponse under wildside-core and keep fields explicit. This matches the workspace split.
133-137: LGTM on CLI flow description.Describe deserialise/solve/emit flow succinctly; this will help acceptance testing later.
|
@sourcery-ai review |
Reviewer's GuideThis PR establishes a new Rust workspace by scaffolding three crates (core, data, CLI), configuring shared linting rules, updating CI workflows, and marking the initial project setup in the roadmap. Class diagram for initial crate structureclassDiagram
class WildsideCore {
<<crate>>
+lib.rs: "Core domain types for the Wildside engine"
}
class WildsideData {
<<crate>>
+lib.rs: "Data access and ingestion logic for the Wildside engine"
}
class WildsideCli {
<<crate>>
+main.rs: "Entrypoint for the command-line interface"
}
WildsideCore <|.. WorkspaceRoot
WildsideData <|.. WorkspaceRoot
WildsideCli <|.. WorkspaceRoot
class WorkspaceRoot {
<<workspace>>
+Cargo.toml: workspace config, shared lints
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (4)
docs/wildside-engine-design.md (2)
259-273: Clarify crate status and align language with workspace reality.The sections introducing wildside-scorer, wildside-solver-vrp, and wildside-solver-ortools describe future crates. Mark them explicitly as “planned” to avoid implying they ship in this PR.
Apply this edit pattern within the listed bullet points:
-- `wildside-scorer`: Implements the `Scorer` trait. +- (Planned) `wildside-scorer`: Implements the `Scorer` trait.Repeat for:
- wildside-solver-vrp
- wildside-solver-ortools
- wildside-cli subcommands that depend on the solver/scorer (if not yet present)
Also applies to: 274-286, 287-294, 295-305
342-355: Spell out artefact formats and stability guarantees.State versioning and compatibility promises for pois.db, pois.rstar, and popularity.bin to aid future migrations and testing.
Append to the list:
- “Embed a file-format version in each artefact header; bump on incompatible changes, provide a migrator in wildside-cli.”
docs/roadmap.md (2)
49-51: Use en‑GB Oxford spelling (-ize) per repository guidelines.Standardise spelling across the document: prefer -ize/-ization forms and keep “LICENSE” as a file literal.
Apply these diffs:
-- [ ] Standardise on `geo::Coord` for all location data within the +- [ ] Standardize on `geo::Coord` for all location data within the-- [ ] ... and normalises the scores. +- [ ] ... and normalizes the scores.-- [ ] It will configure the `vrp-core` problem and objective function to - maximise the total collected score within the given time budget. +- [ ] It will configure the `vrp-core` problem and objective function to + maximize the total collected score within the given time budget.-- [ ] The command will deserialise the JSON into a `SolveRequest`, instantiate +- [ ] The command will deserialize the JSON into a `SolveRequest`, instantiate-## Phase 2: Scoring and Personalisation +## Phase 2: Scoring and Personalization-- [ ] Finalise Licensing and Versioning +- [ ] Finalize Licensing and Versioning-- [ ] Initialise a `CHANGELOG.md` file at the root, documenting the initial +- [ ] Initialize a `CHANGELOG.md` file at the root, documenting the initialAlso applies to: 86-88, 121-123, 132-138, 162-167
157-161: Scope feature flags at the workspace root and document defaults.Define features in the root Cargo.toml and wire-through in each crate to avoid drift.
Append:
- **Implement Feature Flags** - [ ] In the root `Cargo.toml`, define features like `solver-vrp`, `solver-ortools`, and `store-sqlite`. + - [ ] Forward feature flags from member crates using `[features]` and + `dep:`-scoped features to ensure a single source of truth. - [ ] Use `#[cfg(feature = "...")]` attributes to conditionally compile the different solver and store implementations.
♻️ Duplicate comments (1)
.github/workflows/ci.yml (1)
13-17: Replace deprecated actions-rs/toolchain with a maintained action and keep pinning.actionlint flags actions-rs/toolchain as too old for GitHub-hosted runners. Switch to a maintained action and pin to a full-length commit SHA to preserve supply-chain integrity.
Apply one of the following diffs (then pin the action to a commit SHA before merging):
Option A (community-supported):
- - uses: actions-rs/toolchain@63eb9591781c46a70274cb3ebdf190fce92702e8 # v1 - with: - toolchain: nightly-2025-06-26 - components: rustfmt, clippy, llvm-tools-preview - override: true + - uses: actions-rust-lang/setup-rust-toolchain@v1 + with: + toolchain: nightly-2025-06-26 + components: rustfmt, clippy, llvm-tools-preview + override: trueOption B (minimal, commonly used):
- - uses: actions-rs/toolchain@63eb9591781c46a70274cb3ebdf190fce92702e8 # v1 - with: - toolchain: nightly-2025-06-26 - components: rustfmt, clippy, llvm-tools-preview - override: true + - uses: dtolnay/rust-toolchain@master + with: + toolchain: nightly-2025-06-26 + components: rustfmt, clippy, llvm-tools-previewPin either action to a full commit SHA (not a tag) for immutability.
Do not forget to update the pin periodically in Dependabot.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- Jira integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (4)
.github/workflows/ci.yml(1 hunks)Cargo.toml(1 hunks)docs/roadmap.md(9 hunks)docs/wildside-engine-design.md(8 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.md
⚙️ CodeRabbit Configuration File
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/wildside-engine-design.mddocs/roadmap.md
🪛 LanguageTool
docs/wildside-engine-design.md
[uncategorized] ~259-~259: Loose punctuation mark.
Context: ...rates when necessary. - wildside-core: This crate is the heart of the engine. ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~274-~274: Loose punctuation mark.
Context: ... testing and fuzzing. - wildside-data: Contains the ETL logic and data adapter...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~282-~282: Loose punctuation mark.
Context: ...rstar index). - wildside-scorer: Implements the Scorer trait. - Con...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~287-~287: Loose punctuation mark.
Context: ...user relevance. - wildside-solver-vrp: The default, native Rust implementation...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~290-~290: Loose punctuation mark.
Context: ...elibrary. -wildside-solver-ortools: An optional implementation of the Solv...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~295-~295: Loose punctuation mark.
Context: ...ge the C++ dependency. - wildside-cli: A small command-line application for op...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~297-~297: Loose punctuation mark.
Context: ...ion for operational tasks. - ingest: Runs the full ETL pipeline from `wildsi...
(UNLIKELY_OPENING_PUNCTUATION)
🔇 Additional comments (4)
.github/workflows/ci.yml (1)
12-12: Keep actions pinned by commit SHA.Maintain pinning for third-party actions to reduce supply-chain risk. The current pins for actions/checkout and Swatinem/rust-cache are correct.
Also applies to: 18-18
Cargo.toml (3)
1-8: LGTM: virtual workspace with resolver v2 and workspace edition.The workspace layout, explicit resolver v2, and centralised edition are correct and modern.
Also applies to: 9-10
12-46: Validate Clippy lint identifiers against the pinned nightly and gate overly strict lints
- No crate-local
[lints]sections detected; workspace.lints.clippy applies to all members.- Run
on the pinned nightly to catch any unknown or renamed lints.cargo clippy --all-targets --all-features- Add a crate-local override in
wildside-cli/Cargo.tomlto downgrade the strictest rules:--- a/wildside-cli/Cargo.toml +++ b/wildside-cli/Cargo.toml [package] # ... +[lints.clippy] +float_arithmetic = "warn" +print_stdout = "allow" +print_stderr = "allow"
9-10: Note member crates opt in to workspace editionAll member Cargo.toml files already include
edition.workspace = true:
- wildside-cli/Cargo.toml
- wildside-core/Cargo.toml
- wildside-data/Cargo.toml
No changes required.
1 participant
Summary
Testing
make fmtmake check-fmtcargo clippy --workspace --all-targets --all-features -- -D warningsRUSTFLAGS="-D warnings" cargo test --workspace --all-targets --all-featuresmake markdownlintmake nixiehttps://chatgpt.com/codex/tasks/task_e_689e2aa329a88322bd50ec18b0264135
Summary by Sourcery
Scaffold and configure the Wildside Cargo workspace with core, data, and CLI crates, establish shared lints, update CI, and finalize initial project structure in documentation.
Enhancements:
CI:
Documentation: