-
Notifications
You must be signed in to change notification settings - Fork 10
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
Published version of usdt-macro v0.3.3 is pulling in usdt-impl v0.1.14, possibly breaking stable builds #68
Comments
Ugh, sorry @gjcolombo! Thanks for filing this. I'll yank the latest versions to help get things moving. It does look like we need the solution you mentioned. I did something similar to publish the packages, but forgot some of the history there of why they were removed in the first place. |
@gjcolombo's analysis seems accurate. The "right" way to solve this is really to specify both a path dependency and by version. The former is used when building from source, in the workspace, and the latter when publishing to crates.io. It seems an error for us to have removed that previously, so I'll start drafting a PR that pulls those back into place. I'm still not sure how to generally improve the publishing process (see #8), since we need to specify the versions in multiple locations now. Not ideal, but tools like |
Thanks @bnaecker! Yanking v0.3.3 seems to have righted the ship on my local machine. I'm doing another Propolis CI build of the change that hit this to verify the problem's gone there too (I expect it to be). |
Will be resolved by #69 |
Many thanks to @gjcolombo for reporting and investigating, this is now fixed as of #69! New versions have been published. |
I'm trying to build Propolis and have just started seeing build failures in builds that have picked up usdt v0.3.3. The failures are of the form
(This also occurs in Buildomat runs against branches in the repo that shouldn't have any dependency changes.) I'm guessing the problem here is that usdt-impl v0.1.14 doesn't have #52 and so is generally unhappy about being built by a stable compiler but haven't dug into that angle at all.
I did a little digging and suspect (but haven't proven) that the issue here is that crates.io is replacing the
path
dependencies in the repo with registry dependencies and supplying a default version number in the absence of one in the checked-in Cargo.tomls. (The checked-in dependencies used to have version specifiers, but they were removed in #60; this aligns with crates.io's representation that the dependent version numbers were propagated in v0.3.2 but not in v0.3.3.) I'm not sure if the right solution here is just to bring back the version specifiers (it looks like it might be, since that seems to implement the "multiple locations" solution mentioned here) or if it's to do something else.The text was updated successfully, but these errors were encountered: