Merged
Conversation
cla-bot
bot
added
the
cla-signed
agu-z
force-pushed
the
pin-cargo-about
branch
from
ad35b06 to
878b2c8
Compare
JosephTLyons
pushed a commit
that referenced
this pull request
Dec 3, 2025
cargo-about@0.8.3 doesn't seem to like our license identifiers. Pinning to 0.8.2 for now. Release Notes: - N/A
CherryWorm
pushed a commit
to CherryWorm/zed
that referenced
this pull request
Dec 16, 2025
cargo-about@0.8.3 doesn't seem to like our license identifiers. Pinning to 0.8.2 for now. Release Notes: - N/A
someone13574
pushed a commit
to someone13574/zed
that referenced
this pull request
Dec 16, 2025
cargo-about@0.8.3 doesn't seem to like our license identifiers. Pinning to 0.8.2 for now. Release Notes: - N/A
P1n3appl3
pushed a commit
that referenced
this pull request
Dec 16, 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
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
1 participant
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-about@0.8.3 doesn't seem to like our license identifiers. Pinning to 0.8.2 for now.
Release Notes: