-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support extracting package groups from v2+ poetry.lock
files
#1477
Conversation
(fwiw I plan to port this to osv-scalibr tomorrow, so this might end up getting closed but the actual core implementation should still be reviewable) |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1477 +/- ##
==========================================
+ Coverage 66.93% 66.95% +0.01%
==========================================
Files 197 197
Lines 18621 18632 +11
==========================================
+ Hits 12464 12475 +11
Misses 5471 5471
Partials 686 686 ☔ View full report in Codecov by Sentry. |
Closing as this has been landed in |
Poetry v2 lockfiles now include the groups a package belongs to, meaning that we can support extracting them to allow filtering.
Similar to Maven and NPM, Poetry explicitly notes everything that isn't in an explicit group as being in the
main
group meaning for packages that are considered in that group we always use an empty slice instead since that's how we indicate the "production" group.I generated the final fixture using the following
pyproject.toml
:Technically we don't need the
python_version
constraint onproto-plus
for this feature, but I realised we don't have any existing fixtures for this situation so I figured I'd sneak it in as part of this given it seems like we already support the lockfile having a package multiple names with different versionsThis is a sister PR to google/osv-scalibr#376 since
osv-scanner
is still in the middle of transitioning to usingosv-scalibr
- the core logic is exactly the same, and either (or both) should be fine to land