Repository navigation
Conversation
|
Let me take a look. Here's original commit that imposed the version cap: 7b3025c There was probably a dependency conflict; pyparsing isn't used directly in the codebase, so this would have been to deal with some other circle of dependency hell, most likely. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1048 +/- ##
=======================================
Coverage 66.54% 66.54%
=======================================
Files 72 72
Lines 7425 7425
Branches 1307 1307
=======================================
Hits 4941 4941
Misses 2048 2048
Partials 436 436
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Here's the scoop: pyparsing did a PEP8 migration and changed camelCase method names to underscore_style, leaving the old names as shims which matplotlib depended on. But pyparsing 3.3.0 started emitting warnings for the old camel-case calls, and matplotlib 3.9.0 hadn't finished its own PEP8 migration. Evidence:
Meanwhile, CNVkit treats most library warnings as errors to fight bit rot, so the pyparsing < 3.3.0 version cap was required for the plotting code to function at all with matplotlib 3.9.0. Fix: raise the matplotlib minimum version to where it switches to pyparsing's new names: |
Aligns the minimum-supported versions of core deps with the apt-installable versions in Ubuntu 26.04 LTS (Resolute), continuing the project's "track the current Ubuntu" baseline. Matches the previous Plucky-alignment commit (7b3025c) and supersedes it now that 26.04 has released. Also drops the explicit pyparsing pin. It was added in b329cec to cap pyparsing < 3.3.0, which started emitting DeprecationWarning on pre-PEP8 camelCase API calls used by matplotlib's _mathtext.py in 3.8/3.9; under CNVkit's filterwarnings=["error"] those warnings became hard test failures. matplotlib's PEP8 migration (PR #29745) landed in 3.10.7 via the 3.10.x backport, so with matplotlib>=3.10.7 the cap is no longer needed. CNVkit never imported pyparsing directly, so the cleanest fix is to drop the declaration entirely and let matplotlib's own pyparsing>=3 constraint handle it. Closes #1048. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Fixed in #1050 -- thanks for pointing out the issue |
https://github.com/pyparsing/pyparsing
3.3.2is out, and cnvkit still build without issue when upgradingIs there a reason why it is capped at
3.3.0?