Xueqin Cui

yes for now, but this will be replaced by the transitive enricher soon: https://github.com/google/osv-scanner/pull/2294, which I aim to get it in before next OSV-Scanner release.

I tried the implementation for both `tidwall/gjson` and `encoding/json/v2` and benchmarks against both implementations indicate 3 times faster improvements. - However, considering `encoding/json/v2` is still experimental, I am a bit...

this error seems not like a flaky error: both resolution failure should be deterministic if the artifacts don't change - not sure if related to the artifacts from registry. and...

I missed the comments from last week - I will take a look later.

I think this is probably due to the order of packages is not deterministic after grouping them into a map: https://github.com/google/osv-scalibr/blob/main/enricher/transitivedependency/requirements/requirements.go#L86 this should be easy to fix since we already...

however I think pip's [backtracking](https://pip.pypa.io/en/stable/topics/dependency-resolution/#backtracking) dependency resolution may not be affected by the order of dependencies, but this is a thing to follow up with the resolver instead of scalibr....

@G-Rath sorry I merged in the wrong snapshot you may need to re-generate them and push again.

https://github.com/google/osv-scalibr/pull/1532 is merged so I hope the flaky test should be fixed. We probably still want to wait until https://github.com/google/osv-scanner/pull/2328 is in so we can update osv-scalibr further.

@G-Rath could you help to merge the main branch add see if https://github.com/google/osv-scalibr/pull/1532 fixes the flaky test?

Not only tabs are escaped but also other characters: https://github.com/golang/go/blob/master/src/encoding/xml/xml.go#L1916