Add code to expose the selected version of a requested package

[CraftSpider]

Makes it so the version of the port/package requested is added to the library struct returned, so consumers can do things based on what version they have. Also a drive-by add of Clone to Library, which is useful for the downstream I'm making this change for (tectonic-typesetting/tectonic#1138).

This is a breaking change due to Library not being marked #[non_exhaustive] and having all public fields.

[pkgw]

This could be made non-breaking by having the version field be private and adding an associated method, right? I just recently noticed how many downloads vcpkg has which has made me want to be extra-careful about this kind of stuff ...

[CraftSpider]

I'm afraid not - since all the fields are public, outside users could be constructing instances of the type directly, or matching fields exhaustively, and any change to its fields at all is breaking.

It would be possible to add a new API that returns a new type or just this info, though that has repetition/code cleanliness issues. An alternative is to release a breaking version (0.3 I think?), and if lots of people still use 0.2 after a bit, backport any important fixes.

EDIT: If you do want to go with a breaking change, I'd add a ZST private field to Library, which should ensure no outside construction or exhaustive matching. Unfortunately the #[non_exhaustive] attribute is from Rust 1.40, so more of an MSRV bump than I suspect is worth it.

[pkgw]

Hmm, right. @waych Do you have any thoughts on this?

[waych]

Given this crate is so used by others, I agree care is required in justifying the semantic version bump. If we are going to extend the interface at all, we should consider using the opportunity to clean up the crate and do other semantic breaking things at the same time. I think that means iterating here in github for a 0.3 without a push to crates.io until we've bundled enough semantic breakage to make it worthwhile doing.

A possible shortlist of suggestions that could be bundled include: Deleting the parts marked deprecated, fixing the NotMSVC error codes and spaghetti target code, tightening up the types so that they are more private (mark public fields deprecated?) / more semantically extensible in the future, revisit the MSRV. None of these on their own really justify a semantic update, but together they make more sense.

[pkgw]

Yeah, there's definitely a good-sized backlog of maintenance tasks that could benefit from a semver-incompatible bump!
We could also consider bumping to 1.0 — I don't always practice what I preach, but I feel like if a package is sufficiently stable for sufficiently long, you should probably call it 1.0 even if it doesn't "feel ready" for the 1.0 label.

Anyway, I think that I personally don't realistically have the bandwidth to help very much with any effort to make this happen, but I'd be in favor of it.

[CraftSpider]

I already did the easy MSRV cleanups in #57, I'd be willing to take a look at some of the other things on the list when I have a moment. I'll see if I can find some Rust version usage numbers somewhere - if up till 1.30 or so is basically unused, may be worth upping to that to get #[non_exhaustive].

[CraftSpider]

I added a private __non_exhaustive field to Library - the error messages will be slightly worse, but this should give us the same allowances as #[non_exhaustive] would in most cases, since outside users would now be unable to construct or exhaustively match the struct.

[CraftSpider]

Any updates on this?