oli-obk / cargo_metadata

MIT License
171 stars 92 forks source link

Better representation for `Source` #268

Open antonok-edm opened 6 hours ago

antonok-edm commented 6 hours ago

Source is currently represented as a String, and the documentation says:

It is possible to inspect the repr field, if the need arises, but its precise format is an implementation detail and is subject to change.

This is slightly problematic for users of the crate who would inspect this field for the purpose of e.g. downloading the relevant crate. There is already Source::is_crates_io, but other types of sources require custom code to identify and even more custom code to parse out the details relevant to downloading, all of which could be prone to silent breakage if the internal format is updated.

Ideally, Source could have a type-safe representation, like an enum over CratesIo, Git, Path, or Registry. Each variant could provide accessors for relevant details, e.g. The Git variant could provide accessors for the commit reference and a downloadable repo URL.

weihanglo commented 3 hours ago

Ideally, Source could have a type-safe representation, like an enum over CratesIo, Git, Path, or Registry. Each variant could provide accessors for relevant details, e.g. The Git variant could provide accessors for the commit reference and a downloadable repo URL.

For kinds of sources, it is possible to provides such methods, as in the doc of cargo metadata explicitly states that the protocol prefix e.g. git+, registry+. For providing additional information like Git repo URL you mentioned, it is deemed opaque to cargo_metadata crate. Everything after is the prefix is subject to change.

The value after the + is not explicitly defined, and may change between versions of Cargo and may not directly correlate to other things, such as registry definitions in a config file. New source kinds may be added in the future which will have different + prefixed identifiers.