Infer purl from download URL

[pombredanne]

It would be great if we could infer a purl using heuristics based on a URL and/or filename and/or filepath.

These heuristics are package-type specific.

For instance with http://repo1.maven.org/maven2/io/github/subiyacryolite/jds/3.0.1/jds-3.0.1-sources.jar we could get pkg:maven/io.github.subiyacryolite/jds@3.0.1?qualifier=sources&type=jar .

Or from https://api.nuget.org/v3-flatcontainer/newtonsoft.json/10.0.1/newtonsoft.json.10.0.1.nupkg we could infer pkg:nuget/newtonsoft.json@10.0.1

Or a path with github.com/foo/bar (such as from a vendored Go package) could yield pkg:golang/github.com/foo/bar and so on.

Since these would be heuristics and we cannot get 100% success we should return a confidence level with an inferred purl.

[pombredanne]

This could also be useful for #947

[pombredanne]

So here is the status: we do infer download URLs in the package models based on the Package URL fields alright. See for instance https://github.com/nexB/scancode-toolkit/blob/a7de3052d540b2f005960521635e7816f50485a6/src/packagedcode/rubygems.py#L150

@tdruez and @JonoYang did contribute this code in the purl library: https://github.com/package-url/packageurl-python/blob/70a3b32c43a969a22fb7793ab6e19cd4d447d772/src/packageurl/contrib/url2purl.py

Beyond this that can be improved alright, some rules will stay package-type specific and not only URL- of path-specific: for instance inferring a Oo Package URL from vendored path can likely mostly be done reliably if you know that you are dealing with Go in the first place (though a workspace or that would start with go/src/.... would be quite fine as-is