Skip to content

fix: base install no longer implies padatious - #184

Closed
JarbasAl wants to merge 1 commit into
devfrom
fix/no-implicit-padatious
Closed

JarbasAl wants to merge 1 commit into
devfrom
fix/no-implicit-padatious

Conversation

@JarbasAl

@JarbasAl JarbasAl commented Sep 7, 2026

Copy link
Copy Markdown
Member

🤖 Auto-generated by Claude Sonnet 5 (claude-sonnet-5) via Claude Code — NOT human-reviewed. Verify before acting.

Every ovoscope install used to pull in ovos-core[lgpl,plugins], which pulls in ovos_padatious even when a suite only wants the padacioso or Model2Vec pipelines. Padatious registers and trains synchronously in the background, so a padacioso-only test cell was seeing an extra mycroft.skills.trained bus message it never asked for (see OpenVoiceOS/ovos-skill-hello-world#125). Padatious is archived and should not ride along on a bare install.

The dependency is now plain ovos-core>=2.0.4a2. ovos-workshop, one of ovos-core's own dependencies, pins padacioso unconditionally, so a bare install still ships that one pipeline matcher — nothing else.

Extra Adds Used by
(base) padacioso only, transitively via ovos-workshop every install
engines nebulento, Model2Vec, Adapt ovoscope.golden multi-engine runner, the live pipeline harness tests
padatious ovos-core[plugins] (Padatious) suites still exercising the archived legacy matcher
test / dev everything the unit suite imports, including engines CI, local dev

Coverage that silently disappears on a missing optional dependency is a bug in its own right, so the five tests that assumed the full padatious/padacioso/nebulento set was always installed are marked pytest.mark.padatious (registered in pyproject.toml) instead of skipping. CI now runs two lanes on every PR: build_tests (Python 3.10–3.14) installs .[test] and runs -m "not padatious"; a new padatious_cell job (Python 3.11) installs .[test,padatious] and runs -m padatious. One tiny test in each lane asserts ovos-padatious's importability the way that lane expects (present in the padatious cell, absent in the base lane), so a wrong extras list fails loudly instead of quietly changing the pass count. Locally: base lane 681 passed / 27 skipped / 6 deselected; padatious lane 6 passed / 708 deselected.

I checked every consumer in the OVOS org that installs ovoscope[...]: they only use the media and tts extras, neither of which touches padatious, adapt, or [plugins], so this change does not affect them.

Fail-before: in a fresh venv, reverting only the pyproject.toml dependency line and reinstalling pulls in ovos-padatious==2.1.1a1 (and uv warns that ovos-core's current PyPI release no longer even has a [lgpl] extra); with the fix the same install raises PackageNotFoundError for ovos-padatious, import ovoscope still works, and the padacioso OPM pipeline entry point is present via importlib.metadata.

Downstream integration: I installed this checkout editable over a fresh clone of ovos-skill-hello-world's test/drop-padatious branch (with the ovoscope line stripped from its e2e requirements) and ran its padacioso-only cell (TestNoAdaptPipeline): both tests pass, and a manual message capture on the same scenario shows no mycroft.skills.trained message at all.

Unrelated finding: build_tests (3.10) failed three times on test_media.py::TestOCPHarnessNamespaceBridging::test_no_bridging_isolates_spec_from_legacy (PlayerState.STOPPED instead of PLAYING). This repo does not use pytest-randomly (no such plugin is installed or listed in the CI log), so ordering is deterministic, not seed-based. I reproduced it locally on a Python 3.10 venv by running the same ~456-test prefix that precedes it in collection order, but bisecting that prefix in half — and further down to just the real-MiniCroft-booting files — never reproduces it alone; only the full run does. That points to cumulative CPU/thread load exposing a fragile time.sleep(0.05)-then-assert wait in the OCP harness test itself on the slower Python 3.10 interpreter, not a single discrete test leaking state. I did not find a specific leaking test to fix, so I have not opened a follow-up PR guessing at one; this is unrelated to the padatious/extras change in this PR either way.

@github-actions github-actions Bot added the fix label Sep 7, 2026
@coderabbitai

coderabbitai Bot commented Sep 7, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

github-actions Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Automated check summary ready. 📊

I've aggregated the results of the automated checks for this PR below.

🔍 Lint

I've tidied up the results for you. 🧹

ruff: issues found — see job log

🏷️ Release Preview

The roadmap for the future just got clearer. 🗺️

Current: 1.8.0a1Next: 1.8.1a1

Signal Value
Label fix
PR title fix: base install no longer implies padatious
Bump build

✅ PR title follows conventional commit format.


🚀 Release Channel Compatibility

Predicted next version: 1.8.1a1

Channel Status Note Current Constraint
Stable Not in channel -
Testing Too new (must be <1.0.0) ovoscope>=0.7.2,<1.0.0
Alpha Compatible ovoscope>=1.6.15a1

⚖️ License Check

Ensuring our project is well-protected legally. 🛡️

✅ No license violations found.

Policy: Apache 2.0 (universal donor). StrongCopyleft / NetworkCopyleft / WeakCopyleft / Other / Error categories fail. MPL allowed.

📋 Repo Health

Scanning for any signs of 'dependency' parasites. 🐛

✅ All required files present.

Latest Version: 1.8.0a1

ovoscope/version.py — Version file
README.md — README
LICENSE — License file
pyproject.toml — pyproject.toml
⚠️ setup.py — setup.py
CHANGELOG.md — Changelog
ovoscope/version.py has valid version block markers

🔒 Security (pip-audit)

Security check! Are we safe from vulnerabilities? 🛡️

✅ No known vulnerabilities found (77 packages scanned).

📊 Coverage

Testing the limits! Here's the coverage breakdown. 📏

⚠️ 62.5% total coverage

Files below 80% coverage (15 files)
File Coverage Missing lines
ovoscope/simple_listener.py 0.0% 63
ovoscope/version.py 0.0% 5
ovoscope/classic_listener.py 18.2% 117
ovoscope/intent_cases.py 22.3% 153
ovoscope/pytest_plugin.py 47.0% 210
ovoscope/cli.py 47.8% 132
ovoscope/ocp.py 47.9% 61
ovoscope/tts_intelligibility.py 49.0% 102
ovoscope/e2e.py 53.5% 66
ovoscope/media.py 56.7% 101
ovoscope/listener.py 57.1% 127
ovoscope/voice_loop.py 59.0% 119
ovoscope/__init__.py 62.7% 429
ovoscope/audio.py 64.4% 126
ovoscope/media_provider.py 67.6% 23

Full report: download the coverage-report artifact.

🔨 Build Tests

Structural analysis of your contribution is complete. 🔬

Python Build Install Tests
3.10 ⚠️
3.11
3.12
3.13
3.14

❌ 3.10: Install OK, tests failed
Check job logs for details.


Automatically generated, personally appreciated 💖

@JarbasAl
JarbasAl force-pushed the fix/no-implicit-padatious branch from 558cbf8 to 946b949 Compare September 7, 2026 18:23
@github-actions github-actions Bot added fix and removed fix labels Sep 7, 2026
ovoscope's core dependency was ovos-core[lgpl,plugins], so every
harness install pulled in ovos_padatious regardless of what a suite
actually asked for — a padacioso/m2v-only cell saw an extra
mycroft.skills.trained bus message it never subscribed to (Padatious
registers and trains synchronously in the background). Padatious is
being archived and must not be implied by the base install.

The dependency is now plain ovos-core>=2.0.4a2. ovos-workshop (an
ovos-core dependency) pins padacioso unconditionally, so a bare
install still ships one pipeline matcher. Adapt and Model2Vec move
into ovoscope's own `engines` extra (used by the multi-engine golden
runner and the live pipeline harness); a new `padatious` extra
forwards to ovos-core[plugins] for suites that still need the legacy
matcher.

Five tests that exercised the full padatious/padacioso/nebulento
gating set unconditionally are now marked `pytest.mark.padatious`
(registered in pyproject) instead of skipping when the extra is
absent — coverage that silently disappears on a missing dependency is
itself a bug. CI runs both lanes on every PR: `build_tests` installs
`.[test]` and runs `-m "not padatious"`; a new `padatious_cell` job
(Python 3.11 only) installs `.[test,padatious]` and runs `-m
padatious`. One tiny test in each lane asserts ovos-padatious's
importability the way that lane expects, so a wrong extras list fails
loudly instead of quietly changing the count.

Fail-before: reverting only the pyproject.toml dependency line and
reinstalling into a fresh venv pulls in ovos-padatious==2.1.1a1; with
the fix, the same install raises PackageNotFoundError for
ovos-padatious.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@JarbasAl
JarbasAl force-pushed the fix/no-implicit-padatious branch from 946b949 to d722ed1 Compare September 7, 2026 18:35
@JarbasAl JarbasAl closed this Sep 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant