将瞬态git依赖性修补到特定的rev
我依靠板条箱a
和b
,其中我修补了b
to Ref
foo fooo
:
# Cargo.toml of my crate
[dependencies]
a = "1.0.0"
b = "1.0.0"
[patch.crates-io]
b = { git = "https://github.com/user/example", rev = "foo" }
a
还取决于b
作为git依赖性,但没有特定的ref
:
# Cargo.toml of a
[dependencies]
b = { git = "https://github.com/user/example" }
我想强制a
像我一样使用相同的ref
b
,我认为我可以这样做:
# The ideal Cargo.toml of my crate
[dependencies]
a = "1.0.0"
b = "1.0.0"
# patch local dependency
[patch.crates-io]
b = { git = "https://github.com/user/example", rev = "foo" }
# patch transient dependency
[patch.'https://github.com/user/example']
b = { git = "https://github.com/user/example", rev = "foo" }
这是不起作用的修补仍然指向同一源,只是在不同的rev
中:
error: failed to resolve patches for `https://github.com/user/example`
Caused by:
patch for `b` in `https://github.com/user/example` points to the same source, but patches must point to different sources
[Finished running. Exit status: 101]
到目前为止,我的解决方法是叉b
和这样的
# Cargo.toml of my crate using a work around
[dependencies]
a = "1.0.0"
b = "1.0.0"
[patch.crates-io]
b = { git = "https://github.com/me/example", rev = "foo" } # Using my fork
[patch.'https://github.com/user/example']
b = { git = "https://github.com/me/example", rev = "foo" } # Using my fork
修补。有更好的方法吗?
我尝试了此hack 它只是忽略了Rev
。整个GitHub问题使我的尝试似乎不受支持,但很难说,因为它不是完全相同的功能。
I depend on crates a
and b
, where I patched b
to a git dependency on ref
foo
:
# Cargo.toml of my crate
[dependencies]
a = "1.0.0"
b = "1.0.0"
[patch.crates-io]
b = { git = "https://github.com/user/example", rev = "foo" }
a
also depends on b
as a git dependency, but on no specific ref
:
# Cargo.toml of a
[dependencies]
b = { git = "https://github.com/user/example" }
I want to force a
to use the same ref
for b
as I do, which I thought I could do like this:
# The ideal Cargo.toml of my crate
[dependencies]
a = "1.0.0"
b = "1.0.0"
# patch local dependency
[patch.crates-io]
b = { git = "https://github.com/user/example", rev = "foo" }
# patch transient dependency
[patch.'https://github.com/user/example']
b = { git = "https://github.com/user/example", rev = "foo" }
This does not work however, since the source I'm patching still points to the same source, just in a different rev
:
error: failed to resolve patches for `https://github.com/user/example`
Caused by:
patch for `b` in `https://github.com/user/example` points to the same source, but patches must point to different sources
[Finished running. Exit status: 101]
My workaround so far is to fork b
and patch like this:
# Cargo.toml of my crate using a work around
[dependencies]
a = "1.0.0"
b = "1.0.0"
[patch.crates-io]
b = { git = "https://github.com/me/example", rev = "foo" } # Using my fork
[patch.'https://github.com/user/example']
b = { git = "https://github.com/me/example", rev = "foo" } # Using my fork
This works, but the fork is essentially useless. Is there a better way to do this?
I tried this hack, but it does not work either since it just ignores the rev
. The whole GitHub issue makes it look like what I'm trying is not supported at the moment, but it's hard to tell, since it's not exactly the same feature.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
per 此github问题,当前不支持此功能专门通过URL,而不是修订。有些URL被视为相同,例如
.git
结束总是被剥离,但货物仍只是在比较URL,而没有其他。但是,我们可以使用此“功能”来提高我们的优势:在URL的末尾添加
?ref = foo
将使它看起来像是一个新来源:请小心使用两个补丁,否则您将创建一个损坏
cargo.lock
,其中有两个定义b
:虽然我没有测试,但此方法也应原则上通过附加
/tree/< branch>
将分支上的补丁处理。Per this GitHub issue, this feature is currently not supported, since git dependencies are differentiated exclusively via URL, not revision. Some URLs are treated as the same, e.g. the
.git
ending always being stripped, but cargo is still just comparing URLs and nothing else.We can however use this "feature" to our advantage: Adding a
?ref=foo
to the end of the URL will make it look like a new source:Be careful to use the URL hack in both patches, otherwise you will create a corrupt
Cargo.lock
with two definitions ofb
:While I did not test it, this approach should in principle also work with patches on branches by appending
/tree/<branch>
to the URL.