Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Cargo metadata for publish = false crates #248

Merged
merged 1 commit into from
Jan 16, 2024

Conversation

edmorley
Copy link
Member

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.

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.
@edmorley edmorley self-assigned this Jan 15, 2024
@edmorley edmorley marked this pull request as ready for review January 15, 2024 16:28
@edmorley edmorley requested a review from a team as a code owner January 15, 2024 16:28
@edmorley edmorley enabled auto-merge (squash) January 15, 2024 16:29
@edmorley edmorley merged commit 4322def into main Jan 16, 2024
7 checks passed
@edmorley edmorley deleted the edmorley/rm-publish-false branch January 16, 2024 12:04
edmorley added a commit to heroku/buildpacks-nodejs that referenced this pull request Mar 1, 2024
Dependabot is currently failing since it doesn't like the fact that the
version of the Ruby `commons` module (which is imported via a
GitHub URL) has changed from `1.0.0` to `0.0.0` after:
heroku/buildpacks-ruby#248

To fix this the lockfile entry for `commons` needs regenerating.

However, whilst I'm here I've just regenerated the whole lockfile,
to pick up any other in-range version updates.
@schneems
Copy link
Contributor

schneems commented Sep 9, 2024

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
Copy link
Member Author

edmorley commented Sep 9, 2024

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
Copy link
Contributor

schneems commented Sep 9, 2024

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
Copy link
Member Author

edmorley commented Sep 9, 2024

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? :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants