Open alilleybrinker opened 1 year ago
There is a downside to exposing packageurl::PackageUrl
in the public API: every time packageurl
makes a semver-breaking release, we would have to make one too. Switching to another PURL crate would also be semver-breaking.
For now we've instead exposed FromStr implementations for Purl in #381 to make it writable, but without actually transitioning to a foreign type.
Alright, seems like a good enough solution. Do you think documentation could be added to more clearly indicate this is the recommended way to interoperate with the packageurl
crate?
There are several package URL crates in use already. I don't think it makes sense to enumerate every one in the documentation.
I'd be happy to accept a PR adding a code example that uses the FromStr
impl, and a note that other package URL types should be converted to an &str
first.
Right now the crate uses its own
Purl
type, with only hidden fields (which also makes it not terribly useful as-is, except for validation; use of its contents requiresDisplay
-ing and then reparsing withpackageurl::PackageUrl
orurl::Url
anyway). It's probably better to transition this topackageurl::PackageUrl
to enable easier interoperation and enable extraction of the purl's components.