Crates A,B and C are also under development, so need to be published as required, this is what leads to continually having to re-edit toml files. Also, strange things can happen if you have a local version of a crate and do not update the version when changing the source location ( not sure if this has been fixed, but you could get weird compilation failures, having been bitten by this I don't want to repeat the experience ). So in practice I will publish X on crates.io as it is simple and everything works smoothly, even though I know it is under development and unlikely to be permanent.
https://staging.crates.io/ exists, but is entirely separate from the normal crates.io. It isn't populated with content from the normal crates.io.
Again, this isn't needed, as you can point directly at git branches for your dependencies both directly or via patch/override tables in the toml.
1 Like
I couldn't find anything about this when googling for things like "crates.io test instance" etc, so it isn't well advertised. Also, since you can't publish without your dependencies existing, that would make it fairly useless for anything except the most basic of tests.
Perhaps it would be good to adopt the PyPi model for this?
I haven't any idea what git branches even are, much less how to point at them, and I wouldn't ever want to get into something so complicated, my senile old brain would never cope with it.
All I know is what is in "The Book", which I think barely mentions Git except you need a Git account to publish to crates.io
https://doc.rust-lang.org/stable/book/ch14-02-publishing-to-crates-io.html
(The GitHub account is currently a requirement, but the site might support other ways of creating an account in the future.)
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories has documentation on how to use dependencies stored in a git repository.
1 Like
I can see you can do something with git, but honestly that is too complex for me, I would get confused and mess up somehow. I will stick to what is simple.
Are they your own crates? If so you can use a path dependency to wherever you have stored it locally. If not, where did you get the crate from in the first place to be able to upload it to crates.io? If it is in a git repo why would directly depending on this git repo be too complex? And if you aren't releasing your own crate (yet), you can manually clone the git repo and use a path dependency too.
1 Like
I have used a local path dependency in the past. Maybe I misunderstood the need to keep editing the toml file when I do that. My impression ( how I was doing it ) is that it would refuse to publish to crates.io until I edited it to make to a "normal" crates.io dependency. Perhaps there is a syntax I missed that means that is not necessary.
[ I still think overall path and git dependencies are just too fiddly and complicated for me to cope with, mostly. I mean I will use them if it is really essential, but prefer to just use normal crates.io dependencies "normally" to avoid any confusion (in my own mind). I am hyper-forgetful due to my age. ]
The ability to declare a publication to crates.io "provisional" ( or "prototype" or whatever ) without any major change to semantics other than warnings being issued and it being possible to simply delete the publication entirely (or promote it to permanent ) would be very nice.
Both can be used simultaneously.
[dependencies]
my-crate = { version = "0.1", path = "./crates/my-crate" }
The semantics of using both means that cargo will prefer the path if it's building in a context where the path could exist, or else it will fallback to a crate repository (which is almost always crates.io but can be configured to use an alternative crate repository) with the version specification.
It's finicky managing dependencies this way, but sometimes it makes the development process far easier.
2 Likes