Add support for Hex packages about ort HOT 4 CLOSED

@adambhere looking at above comments in the description I thought I'd share my two cents on requirement 1: Actually I can't see an issue with projects using both, mix and rebar, like the mentioned ssl_verify_fun project does. We could have two completely independent package manager implementation for mix and rebar which would result in (1) a mix and (2) a rebar project being detected. It's up to the user then to exclude the not relevant one(s) via path excludes.

That is to say that we would not need any heuristic which determines which package manager is to be used. Using such heuristic rather seems in general a bad idea as it possibly couldn't be implemented to always make the right decision.

from ort.

To analyze Hex packages we may be able to use https://github.com/voltone/sbom. Maybe Bram Verburg (@voltone) is willing to help us - let me try to reach out to him.

from ort.

Let's first talk about Mix and Rebar3, putting Erlang.mk aside for now...

You probably won't encounter multiple build files in top-level projects: they are typically used to allow a package to be used as a dependency in both Erlang projects and Elixir projects. It is up to the build tool used at the project top-level to pick the correct file for the dependency subtree it is building (or, before that, for dependency resolution).

The lock files do not contain sufficient information, so I think one way or another you're going to have to call out to the build tool. Which tool should be used can be determined based on the presence of the lock file.

There is good news and bad news about both Rebar3 and Mix:

Rebar3, unlike Mix, defines a public API for fetching dependency information rebar_state:all_deps/1. Unfortunately I don't think it is possible to call it from a script, the way e.g. bundler_dependencies.rb does for Ruby. It is part of the plugin API, so it seems the user would have to add a plugin, such as rebar3_sbom, to the project in order to make the data available to Analyzer. Not sure if that's acceptable/practical.

As for Mix, it should be possible to introspect a project from a one-off script. Unfortunately there is no public API like there is in Rebar3, so the script would have to rely on undocumented internals of Mix/Hex. I've been meaning to define the minimum functionality needed, so I can propose an API to the Mix/Hex teams, but that doesn't help you right now.

In both cases, fetching the packages is best left to the build tools themselves, the introspection functions should provide information about the declared license, or you can look up the path where the package is installed and look for license files there.

Hope this helps. I haven't used oss-review-toolkit myself, and I'm not familiar with the constraints you have for interacting with build tools and package repos. Let me know what you think based on the above and I'll be happy to see if I can help move things forward.

from ort.

Closed as part of backlog grooming. Feel free to comment if you would like to contribute to this.

from ort.