Simplify Cargo metadata for `publish = false` crates

[edmorley]

As of Cargo 1.75 the version property in Cargo.toml is now optional, and if omitted is the same as having specified version = "0.0.0" and publish = false: https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-175-2023-12-28 https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field

Therefore for crates that we do not publish, we can now remove both the version and publish properties, avoiding the need for the fake 0.0.0 version that differs from the actual buildpack version in buildpack.toml.

GUS-W-14821120.

[schneems]

The commons crate is intended to be used by other buildpacks even if it's never intended to be published to a registry. I'm in the process of deprecating some features from it right now.

[edmorley]

The commons crate is intended to be used by other buildpacks even if it's never intended to be published to a registry.

Yes, we know :-) Since it's a Git dep, other buildpacks use it via the Git repo URL, which Cargo resolves to a commit SHA, eg: https://github.com/heroku/buildpacks-nodejs/blob/cbd26dbbc9b8318d380b697aef0666102b04d3a1/buildpacks/nodejs-npm-engine/Cargo.toml#L10 https://github.com/heroku/buildpacks-nodejs/blob/cbd26dbbc9b8318d380b697aef0666102b04d3a1/Cargo.lock#L207

...so the version is unused and makes no difference on the consumer side.

[schneems]

TIL, I assumed that you could use a version specifier with a git dependency, but no one had chosen to do so. This is how it works in Ruby:

$ cat Gemfile
source 'https://rubygems.org'

gem "mini_histogram", "~> 1.0", git: "https://github.com/zombocom/mini_histogram"
⛄️ 3.3.1 🚀 /tmp/a7704e6bca17b87f9f0f93c3b5003a7c (main)
$ bundle
Fetching https://github.com/zombocom/mini_histogram
Could not find gem 'mini_histogram (~> 1.0)' in https://github.com/zombocom/mini_histogram (at main@bfde0ab).

The source contains the following gems matching 'mini_histogram':
  * mini_histogram-0.3.1

[edmorley]

I'm pretty sure with most language's packages managers, the way you manage a Git based dependency is via a Git ref rather than directly via the package version, and if a package version is involved at any point it's more of a ancillary side-effect rather than the actual means of picking the version to use. If instead the package version was the primary means of selecting the version, how would the packager manager know which branch/tag/revision to check out to install the package etc? :-)