You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I have multiple interdependent packages that I keep in version sync and publish together. If I try to publish a dependent package after a package it depends on too quickly, the process can sometimes fail.
More specifically, I have a set of packages that I publish with a script. They are published in an order that allows all of their dependencies be met, e.g., if A depends upon B, then B is published before A.
The packages' requirements on one another are strict: If A depends upon B, and B is at version X, then A's requirement for B is =X.
Finally, the packages are kept in version sync: they'll all be at some version X, I'll change all of their versions to Y, change all of their respective requirements to =Y, and then run the script.
The problem is: cargo publish will sometime fail because A's requirement for B cannot be met, even though B was published just moments ago.
I tried two workarounds for this:
Check that curl "https://crates.io/api/v1/crates/B" | jq -r '.crate | .newest_version' is Y.
Check that curl "https://crates.io/api/v1/crates/B/versions" | jq -r '.versions | map(.num) | .[]' includes Y.
Neither seems to work. For example, B's .newest_version can be Y, yet A's requirement for version Y of B can fail to be met.
My current workaround is to just re-run the script, but I would prefer a more elegant solution.
So, my question is: is there a reliable way to tell when version Y of package B has been published? That is, is there a check that, when successful, ensures a requirement for version Y of package B will be met?
To Reproduce
Steps to reproduce the behavior:
Create two interdependent packages A and B with the same version Y, and such that A's requirement for B is =Y.
Publish version Y of B.
Immediately try to publish version Y of A.
Expected behavior
In the above scenario, I would expect cargo publish to succeed for for version Y of package A once any of the following become true:
Version Y of B is published.
curl "https://crates.io/api/v1/crates/B" | jq -r '.crate | .newest_version' is Y.
curl "https://crates.io/api/v1/crates/B/versions" | jq -r '.versions | map(.num) | .[]' includes Y.
Screenshots
N/A
Desktop (please complete the following information):
The scripts are run from a GitHub action in ubuntu-latest.
Smartphone (please complete the following information):
N/A
This discussion was converted from issue #3512 on December 23, 2021 00:21.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Describe the bug
I have multiple interdependent packages that I keep in version sync and publish together. If I try to publish a dependent package after a package it depends on too quickly, the process can sometimes fail.
More specifically, I have a set of packages that I publish with a script. They are published in an order that allows all of their dependencies be met, e.g., if
A
depends uponB
, thenB
is published beforeA
.The packages' requirements on one another are strict: If
A
depends uponB
, andB
is at versionX
, thenA
's requirement forB
is=X
.Finally, the packages are kept in version sync: they'll all be at some version
X
, I'll change all of their versions toY
, change all of their respective requirements to=Y
, and then run the script.The problem is:
cargo publish
will sometime fail becauseA
's requirement forB
cannot be met, even thoughB
was published just moments ago.I tried two workarounds for this:
curl "https://crates.io/api/v1/crates/B" | jq -r '.crate | .newest_version'
isY
.curl "https://crates.io/api/v1/crates/B/versions" | jq -r '.versions | map(.num) | .[]'
includesY
.Neither seems to work. For example,
B
's.newest_version
can beY
, yetA
's requirement for versionY
ofB
can fail to be met.My current workaround is to just re-run the script, but I would prefer a more elegant solution.
So, my question is: is there a reliable way to tell when version
Y
of packageB
has been published? That is, is there a check that, when successful, ensures a requirement for versionY
of packageB
will be met?To Reproduce
Steps to reproduce the behavior:
A
andB
with the same versionY
, and such thatA
's requirement forB
is=Y
.Y
ofB
.Y
ofA
.Expected behavior
In the above scenario, I would expect
cargo publish
to succeed for for versionY
of packageA
once any of the following become true:Y
ofB
is published.curl "https://crates.io/api/v1/crates/B" | jq -r '.crate | .newest_version'
isY
.curl "https://crates.io/api/v1/crates/B/versions" | jq -r '.versions | map(.num) | .[]'
includesY
.Screenshots
N/A
Desktop (please complete the following information):
The scripts are run from a GitHub action in
ubuntu-latest
.Smartphone (please complete the following information):
N/A
Additional context
N/A
Beta Was this translation helpful? Give feedback.
All reactions