How are project-specific version constraints / version conflict resolutions handled?

[sschuberth]

When resolving dependencies of a project, often the final versions of (transitive) dependencies do not match exactly the dependency versions as declared in the parent dependency. This is e.g. due to build-system-inherent version conflict resolution (like Maven's "nearest wins" or Gradle's "latest wins") if the same dependency occurs multiple times in different versions in the tree, or due to custom version constraints / substitutions done in the project's build files.

Is there a plan to account for such things in the service? If so, how?

[andrew]

Currently this service is using https://github.com/jhawthorn/pub_grub for the resolution of every ecosystem and it doesn't take into account any special features of individual package manager right now.

Eventually I'd like to be able to shell out to individual package manager cli's, like dependabot does, but haven't got round to that yet.

[sschuberth]

shell out to individual package manager cli's, like dependabot does

FWIW, my understanding is that dependabot does not shell out to package manager cli's, but statically parses package manager configuration files. See e.g.

https://github.com/dependabot/dependabot-core/blob/main/bundler/lib/dependabot/bundler/file_parser/gemfile_declaration_finder.rb

or even worse

https://github.com/dependabot/dependabot-core/blob/main/gradle/lib/dependabot/gradle/file_parser/property_value_finder.rb

Needless to say that such an implementation is fragile and bears a risk of reporting false dependencies.

In contrast to that, tools like the ORT analyzer do shell out to package manager cli's, or use package manager code programmatically to get the exact dependencies in a project's context. Disclaimer: I'm a maintained or ORT. Feel free to reach out if you're interested in using ORT as part of your service.

[andrew]

I'm now using git-pkgs/resolve under the hood to drive the individual package manager resolvers for more reliable results

[sschuberth]

Ah, that sounds pretty much like what we're doing in the individual analyzers of the OSS Review Toolkit, see e.g. this.