Implements template-based project creation allowing teams to start with
professional example code instead of empty projects.
Features:
- Two templates: 'basic' (minimal) and 'testing' (45-test showcase)
- Template variable substitution ({{PROJECT_NAME}}, etc.)
- Template validation with helpful error messages
- `weevil new --list-templates` command
- Templates embedded in binary at compile time
Testing template includes:
- 3 complete subsystems (MotorCycler, WallApproach, TurnController)
- Hardware abstraction layer with mock implementations
- 45 comprehensive tests (unit, integration, system)
- Professional documentation (DESIGN_AND_TEST_PLAN.md, etc.)
Usage:
weevil new my-robot # basic template
weevil new my-robot --template testing # testing showcase
weevil new --list-templates # show available templates
This enables FTC teams to learn from working code and best practices
rather than starting from scratch.
All 62 tests passing.
Nine end-to-end tests for the proxy feature: 6 network tests exercising
every proxy code path through a real hyper forward proxy (TestProxy) and
a mockito origin, plus 3 CLI tests verifying flag parsing and error handling.
TestProxy binds to 127.0.0.1:0, forwards in absolute-form, counts requests
via an atomic so we can assert traffic actually traversed the proxy.
Key issues resolved during implementation:
- ENV_MUTEX serializes all tests that mutate HTTPS_PROXY/HTTP_PROXY in both
the unit test module and the integration suite. Without it, parallel test
execution within a single binary produces nondeterministic failures.
- reqwest's blocking::Client owns an internal tokio Runtime. Dropping it
inside a #[tokio::test] async fn panics on tokio >= 1.49. All reqwest
work runs inside spawn_blocking so the Client drops on a thread-pool
thread where that's permitted.
- service_fn's closure can't carry a return-type annotation, and async
blocks don't support one either. The handler is extracted to a named
async fn (proxy_handler) so the compiler can see the concrete
Result<Response, Infallible> and satisfy serve_connection's Error bound.
Replace all hardcoded "1.1.0" version strings with env!("CARGO_PKG_VERSION")
in src/, so Cargo.toml is the sole source for the built binary. Tests
intentionally use a separate hardcoded constant in tests/common.rs to act
as a canary — they will fail on a version bump until manually updated.
- src/project/mod.rs: add WEEVIL_VERSION const, wire into Tera context,
generated README, and .weevil-version marker
- tests/common.rs: new file, holds EXPECTED_VERSION for all test crates
- tests/{integration,project_lifecycle,unit/config_tests}.rs: pull from
common instead of env! or inline literals
Adds WEEVIL_HOME-based test isolation so cargo test never touches
the real system. All commands run against a fresh TempDir per test.
Environment tests cover doctor, uninstall, new, and setup across
every combination of missing/present dependencies. Project lifecycle
tests cover creation, config persistence, upgrade, and build scripts.
Full round-trip lifecycle test: new → gradlew test → gradlew
compileJava → uninstall → doctor (unhealthy) → setup → doctor
(healthy). Confirms skeleton projects build and pass tests out of
the box, and that uninstall leaves user projects untouched.
34 tests, zero warnings.
Fixes critical bugs in Windows APK deployment workflow including APK path
resolution, adb integration, and config file parsing.
Changes:
- Fix APK search to look for TeamCode-debug.apk instead of *app-debug.apk
- Strip both single and double quotes from batch file path parsing
- Add android_sdk_path to project configuration (.weevil.toml)
- Resolve adb.exe from Android SDK platform-tools directory
- Check adb install exit code and report deployment failures correctly
- Add migration support for old .weevil.toml files missing android_sdk_path
- Update all tests to use new ProjectConfig::new() signature
The deployment workflow now properly finds the generated APK, locates adb,
and reports success/failure accurately on Windows.
Cross-platform tool for generating clean, testable FTC robot projects
without editing the SDK installation.
Features:
- Standalone project generation with proper separation from SDK
- Per-project SDK configuration via .weevil.toml
- Local unit testing support (no robot required)
- Cross-platform build/deploy scripts (Linux/macOS/Windows)
- Project upgrade system preserving user code
- Configuration management commands
- Comprehensive test suite (11 passing tests)
- Zero-warning builds
Architecture:
- Pure Rust implementation with embedded Gradle wrapper
- Projects use deployToSDK task to copy code to FTC SDK TeamCode
- Git-ready projects with automatic initialization
- USB and WiFi deployment with auto-detection
Commands:
- weevil new <name> - Create new project
- weevil upgrade <path> - Update project infrastructure
- weevil config <path> - View/modify project configuration
- weevil sdk status/install/update - Manage SDKs
Addresses the core problem: FTC's SDK structure forces students to
edit framework internals instead of separating concerns like industry
standard practices. Weevil enables proper software engineering workflows
for robotics education.
