nix: Pin cargo-about to 0.8.2#44901
Merged
P1n3appl3 merged 5 commits intozed-industries:mainfrom Dec 16, 2025
Merged
Conversation
|
We require contributors to sign our Contributor License Agreement, and we don't have @jrobsonchase on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'. |
maxdeviant
changed the title
cargo-about to 0.8.2
Contributor
Author
|
@cla-bot check |
cla-bot
bot
added
the
cla-signed
|
The cla-bot has been summoned, and re-checked this pull request! |
Contributor
Author
|
Oh, hah. I just realized that if I had just read the reformatted sections of So that's definitely an option and might be cleaner than the vendored file. Happy to switch to that approach! |
jrobsonchase
force-pushed
the
nix-pin-cargo-about
branch
from
368a431 to
144501f
Compare
jrobsonchase
changed the title
cargo-about to 0.8.2cargo-about to 0.8.2
jrobsonchase
changed the title
cargo-about to 0.8.2cargo-about to 0.8.2
Contributor
Author
|
Alright, done futzing with this now, sorry about the thrashing 🙏 |
Contributor
thanks for making the change, was about to leave a comment pointing at #28061 😅 fwiw there now is a nixpkgs PR that makes the change that the comment describes; hopefully we'll be able to switch to just a normal Lines 110 to 113 in 0410b23 |
HactarCE
pushed a commit
that referenced
this pull request
Dec 17, 2025
`cargo-about` got pinned to 0.8.2 in #44012, but this isn't exactly "easy" to accomplish in nix. The version of nixpkgs in the flake inputs uses the proper version, but if you override the nixpkgs input or use the provided overlay, you might end up trying to build with a bad version of `cargo-about`. Since nixpkgs is versioned as a whole, your options are (in rough order of desirability): 1. Hope that nixpkgs simply includes multiple versions of the same package (common for things with stable major versions/breaking changes) 1. Use either `override` or `overrideAttrs` to provide different version/source attributes 1. Depend on multiple versions of nixpkgs to get the specific versions of the packages you want 1. Vendor the whole package build from a specific point in its history Option 1 is out - there's only one version of cargo-about in nixpkgs. Option 2 doesn't seem to work due to the way that `buildRustPackage` wraps the base `mkDerivation` which provides the `override` extension functions. There *might* be a way to make this work, but I haven't dug into the `buildRustPackage` internals enough to say for sure. Edit: I apparently can't read and the problems with this option were already solved for `cargo-bundle`, so this is the final approach! Option 3 always just feels a bit icky and opaque to me. Leaving Option 4. I usually find this approach to be "fine" for small package definitions that aren't actually much bigger than the overridden attributes would have be with the Option 2 approach. ~~Since the `cargo-about` definition is nice and small, this is the approach I chose.~~ ~~Since this has the potential to require a build of `cargo-about`, I'm only actually invoking its build if the provided version is wrong - more or less the same thing that's happening in the `generate-licenses` script, but nix-y.~~ Edit: Shouldn't ever cause a rebuild since there's only one 0.8.2 input source/vendored deps, so anything that was already using it will already be cached. I'm also updating nixpkgs to the latest unstable which currently has `cargo-about 0.8.4` to prove that this works. Unrelatedly, I also ran `nix fmt` as a drive-by change. `nix/build.nix` was a bit out of spec. Release Notes: - N/A
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
`cargo-about` got pinned to 0.8.2 in zed-industries#44012, but this isn't exactly "easy" to accomplish in nix. The version of nixpkgs in the flake inputs uses the proper version, but if you override the nixpkgs input or use the provided overlay, you might end up trying to build with a bad version of `cargo-about`. Since nixpkgs is versioned as a whole, your options are (in rough order of desirability): 1. Hope that nixpkgs simply includes multiple versions of the same package (common for things with stable major versions/breaking changes) 1. Use either `override` or `overrideAttrs` to provide different version/source attributes 1. Depend on multiple versions of nixpkgs to get the specific versions of the packages you want 1. Vendor the whole package build from a specific point in its history Option 1 is out - there's only one version of cargo-about in nixpkgs. Option 2 doesn't seem to work due to the way that `buildRustPackage` wraps the base `mkDerivation` which provides the `override` extension functions. There *might* be a way to make this work, but I haven't dug into the `buildRustPackage` internals enough to say for sure. Edit: I apparently can't read and the problems with this option were already solved for `cargo-bundle`, so this is the final approach! Option 3 always just feels a bit icky and opaque to me. Leaving Option 4. I usually find this approach to be "fine" for small package definitions that aren't actually much bigger than the overridden attributes would have be with the Option 2 approach. ~~Since the `cargo-about` definition is nice and small, this is the approach I chose.~~ ~~Since this has the potential to require a build of `cargo-about`, I'm only actually invoking its build if the provided version is wrong - more or less the same thing that's happening in the `generate-licenses` script, but nix-y.~~ Edit: Shouldn't ever cause a rebuild since there's only one 0.8.2 input source/vendored deps, so anything that was already using it will already be cached. I'm also updating nixpkgs to the latest unstable which currently has `cargo-about 0.8.4` to prove that this works. Unrelatedly, I also ran `nix fmt` as a drive-by change. `nix/build.nix` was a bit out of spec. Release Notes: - N/A
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
`cargo-about` got pinned to 0.8.2 in zed-industries#44012, but this isn't exactly "easy" to accomplish in nix. The version of nixpkgs in the flake inputs uses the proper version, but if you override the nixpkgs input or use the provided overlay, you might end up trying to build with a bad version of `cargo-about`. Since nixpkgs is versioned as a whole, your options are (in rough order of desirability): 1. Hope that nixpkgs simply includes multiple versions of the same package (common for things with stable major versions/breaking changes) 1. Use either `override` or `overrideAttrs` to provide different version/source attributes 1. Depend on multiple versions of nixpkgs to get the specific versions of the packages you want 1. Vendor the whole package build from a specific point in its history Option 1 is out - there's only one version of cargo-about in nixpkgs. Option 2 doesn't seem to work due to the way that `buildRustPackage` wraps the base `mkDerivation` which provides the `override` extension functions. There *might* be a way to make this work, but I haven't dug into the `buildRustPackage` internals enough to say for sure. Edit: I apparently can't read and the problems with this option were already solved for `cargo-bundle`, so this is the final approach! Option 3 always just feels a bit icky and opaque to me. Leaving Option 4. I usually find this approach to be "fine" for small package definitions that aren't actually much bigger than the overridden attributes would have be with the Option 2 approach. ~~Since the `cargo-about` definition is nice and small, this is the approach I chose.~~ ~~Since this has the potential to require a build of `cargo-about`, I'm only actually invoking its build if the provided version is wrong - more or less the same thing that's happening in the `generate-licenses` script, but nix-y.~~ Edit: Shouldn't ever cause a rebuild since there's only one 0.8.2 input source/vendored deps, so anything that was already using it will already be cached. I'm also updating nixpkgs to the latest unstable which currently has `cargo-about 0.8.4` to prove that this works. Unrelatedly, I also ran `nix fmt` as a drive-by change. `nix/build.nix` was a bit out of spec. Release Notes: - N/A
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Feb 15, 2026
`cargo-about` got pinned to 0.8.2 in zed-industries#44012, but this isn't exactly "easy" to accomplish in nix. The version of nixpkgs in the flake inputs uses the proper version, but if you override the nixpkgs input or use the provided overlay, you might end up trying to build with a bad version of `cargo-about`. Since nixpkgs is versioned as a whole, your options are (in rough order of desirability): 1. Hope that nixpkgs simply includes multiple versions of the same package (common for things with stable major versions/breaking changes) 1. Use either `override` or `overrideAttrs` to provide different version/source attributes 1. Depend on multiple versions of nixpkgs to get the specific versions of the packages you want 1. Vendor the whole package build from a specific point in its history Option 1 is out - there's only one version of cargo-about in nixpkgs. Option 2 doesn't seem to work due to the way that `buildRustPackage` wraps the base `mkDerivation` which provides the `override` extension functions. There *might* be a way to make this work, but I haven't dug into the `buildRustPackage` internals enough to say for sure. Edit: I apparently can't read and the problems with this option were already solved for `cargo-bundle`, so this is the final approach! Option 3 always just feels a bit icky and opaque to me. Leaving Option 4. I usually find this approach to be "fine" for small package definitions that aren't actually much bigger than the overridden attributes would have be with the Option 2 approach. ~~Since the `cargo-about` definition is nice and small, this is the approach I chose.~~ ~~Since this has the potential to require a build of `cargo-about`, I'm only actually invoking its build if the provided version is wrong - more or less the same thing that's happening in the `generate-licenses` script, but nix-y.~~ Edit: Shouldn't ever cause a rebuild since there's only one 0.8.2 input source/vendored deps, so anything that was already using it will already be cached. I'm also updating nixpkgs to the latest unstable which currently has `cargo-about 0.8.4` to prove that this works. Unrelatedly, I also ran `nix fmt` as a drive-by change. `nix/build.nix` was a bit out of spec. Release Notes: - N/A
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cargo-aboutgot pinned to 0.8.2 in #44012, but this isn't exactly "easy" to accomplish in nix. The version of nixpkgs in the flake inputs uses the proper version, but if you override the nixpkgs input or use the provided overlay, you might end up trying to build with a bad version ofcargo-about.Since nixpkgs is versioned as a whole, your options are (in rough order of desirability):
overrideoroverrideAttrsto provide different version/source attributesOption 1 is out - there's only one version of cargo-about in nixpkgs.
Option 2 is already being used for
cargo-bundle, so it seems best to continue the existing pattern.Option 3 always just feels a bit icky and opaque to me.
Option 4 is usually"fine" for small package definitions that aren't actually much bigger than the overridden attributes would have be with the Option 2 approach. I couldn't get 2 working before noticing that the problems had been solved already, so I had originally taken this approach.
This shouldn't ever cause an unnecessary rebuild since there's only one 0.8.2 input source, so anything that was already using it will already be cached.
I'm also updating nixpkgs to the latest unstable which currently has
cargo-about 0.8.4to prove that this works.Unrelatedly, I also ran
nix fmtas a drive-by change.nix/build.nixwas a bit out of spec.Release Notes: