Refactor package scanning to produce packages instead of queries #614
Conversation
osv.BatchedQuery We are planning to create deps.dev queries from these packages. Rather than use the osv.BatchedQuery type to construct deps.dev queries from, create a new type Package that includes package information and source information.
Codecov Report
@@ Coverage Diff @@
## main #614 +/- ##
==========================================
+ Coverage 80.30% 80.33% +0.03%
==========================================
Files 78 78
Lines 5381 5406 +25
==========================================
+ Hits 4321 4343 +22
- Misses 885 887 +2
- Partials 175 176 +1
|
pkg/osvscanner/osvscanner.go
Outdated
| @@ -505,6 +516,15 @@ func parseLockfilePath(lockfileElem string) (string, string) { | |||
| return splits[0], splits[1] | |||
| } | |||
|
|
|||
| type Package struct { | |||
There was a problem hiding this comment.
Can you make this private? (is there any public functions that take this struct in?) We want to reduce the amount of stuff made public to make future refactoring easier.
Also can you name it something like queryPackage to make it clear what it's purpose is.
There was a problem hiding this comment.
Hmm... now that I think about it, do we even need this intermediate type? It looks like what we're looking for is just the osv.Query type, but rather than being appended to a pointer being passed in, we return it as an array.
This should reduce the number of changes while still accomplishing what you want right?
There was a problem hiding this comment.
I make a separate Package object because it doesn't make semantic sense to use an osv.Query object to create a depsdev query. While it might be possible to do so, I think it's a misuse of the meaning of the osv.Query object and we should be making osv and depsdev queries from an abstracted package object instead.
In the case where commit information and package information are available, it's valid to just construct an osv.Query that just contains just the commit [1]. in this case we wouldn't be able to construct a depsdev query from the osv query. I'm not sure whether this scenario exists yet, but I think it illustrates why it's cleaner to have a separate package object.
As discussed offline I'll make this a private type and submit it as is!
this is in preparation for the license scanning feature. the queries are structured around making requests to the osv API, we also will want to make requests to the deps.dev api.
#501