Do we really want to go down that rabbit hole of pinning git repositories?

Also doesn't this require the most recent version of cargo to actually work?

Do we really want to go down that rabbit hole of pinning git repositories?

I would prefer not to, but I am not sure if cargo-project is currently maintained. If a new version of it is published, we can (and should) always switch to that.

Also doesn't this require the most recent version of cargo to actually work?

Which part? Member globs have been working for a while now. (probe-rs requires Rust 1.38 anyways, and that version works fine even with this)

Which part? Member globs have been working for a while now. (probe-rs requires Rust 1.38 anyways, and that version works fine even with this)

I thought the permission to depend on git repositories (if the version is pinned to a commit) in published crates was only recently added? If that works with Rust 1.38 then it should be fine.

Ah, that's true, it means we can only publish from 1.39.0. 1.38.0 should be able to install that though. And if it can't, we can always publish a temporary crate.

Actually that's not true, the dependency still needs to be published on crates.io. git-only dependencies do not work.

I was thinking of rust-lang/cargo#7333

That's only for dev-dependencies and will probably never be supported for normal dependencies. Everything on crates.io is supposed to build without depending on external sources.

@jonas-schievink Yes I am aware. Just saying that was what I was thinking of when figuring out whether your change might potentially be acceptable. ;) But in this case I'd say it is not.

cargo-project 0.2.3 has been released