-
Notifications
You must be signed in to change notification settings - Fork 26
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
Include commit hashes for git dependencies #122
Comments
@figsoda would this cause any issues for Nix, e.g. blow up the binary size? I understand Nix uses Git a lot in its workflows. When the package is built, does it refer to other packages locally (by path), to a git repo (i.e. @jcgruenhage same question for Void Linux |
Another option would be to include the tree hash instead of commit hash. This is invariant to commit message rewords and squash merges when the original commit was already based on the latest commit of the target branch. In addition it would be possible to record the tree hash for just the subdirectory of the respective crate, thus increasing the likelihood of being able to go back to the source of this specific crate when eg force pushing a change to a different crate in a mono repo. |
That's a good point, but on the other hand I don't really want to diverge from the hash recorded in |
It shouldn't cause any issue afaict, the sources are vendored from crates.io in a separate derivation (package) and replaces crates.io in the actual build with this cargo config. The [source.crates-io]
replace-with = "vendored-sources"
[source.vendored-sources]
directory = "..." |
Shouldn't cause any trouble for Void, no. We're sourcing software from tarballs as published either by the upstream on their dev platform (such as github/gitlab/sourcehut/etc), or if that's not available from crates.io. Outside of patching dependencies in some exceptions, we're also not doing any source replacements or changing the dependencies described in the Cargo.toml, so should be perfectly fine for us :) |
Hi all 👋 Any rough ETA when this feature might be released? |
@eminence life happened, and I am currently occupied with other things. If you have use cases for this feature I could bump up the priority of cutting a release. I'd appreciate if you could tell me what your use case is. I need to understand the needs of the users so that I don't accidentally break the use case in the future. |
At work, I have binaries that depend on several internal git dependencies (we don't have an internal crate repo to use). The version number stored in the embedded manifest is not sufficient to exactly identify the version of the git dependency. So I'm interested in having the hash of the git dependency. I thought that the implementation in #123 would solve this. However, I just did a test and I'm not actually seeing the git hashes (when extracted via the rust-audit-info tool). Here's what I'm seeing: {
"name": "terminal_size",
"version": "0.2.6",
"source": "git",
"dependencies": [
140
]
}, For completeness, here is how I tested:
|
@Adhalianna I'd appreciate if you could take a look if you're available. If not, that's fine too. |
Add a new
commit
field to track what the exact commit on which the dependency was built. It should only be included whenSourceKind
isgit
.The final entry would look like this:
commit: "311f9932128667b8b18113becdea276b3d98aace"
The text was updated successfully, but these errors were encountered: