-
Notifications
You must be signed in to change notification settings - Fork 411
Fix background-processor
doc build for futures
#1744
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
Fix background-processor
doc build for futures
#1744
Conversation
Added a CI check with 47f0101. @TheBlueMatt does this sufficiently cover what you had in mind in #1739, or do we want further CI, e.g., running |
Codecov ReportBase: 90.79% // Head: 90.78% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1744 +/- ##
==========================================
- Coverage 90.79% 90.78% -0.02%
==========================================
Files 87 87
Lines 46969 46969
Branches 46969 46969
==========================================
- Hits 42645 42639 -6
- Misses 4324 4330 +6
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
2a9b0dc
to
07e7c25
Compare
- toolchain: 1.41.1 | ||
build-no-std: false | ||
test-log-variants: true | ||
build-futures: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not test on MSRV? In fact, why not test on all builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I wasn't sure whether we wanted to give it that much resources. Now building on all platforms/toolchains with 1a55192.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yikes, this just got a bit more relevant, since it fails to build under MSRV. To quote the futures
repo README: "The current futures requires Rust 1.45 or later."
So 0.0.111 had an effective MSRV of 1.45 it seems ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now 'solved' by pinning the futures
crates' versions to the last one with MSRV 1.41 (c367f71). Let me know if that's acceptable, or if we're okay with an MSRV of 1.45.2 for the lightning-background-processor
crate.
I'm however unsure why macos-latest
and windows-latest
stable targets are hanging with "Waiting for status to be reported". Any ideas?
769e703
to
c367f71
Compare
futures-executor = { version = "=0.3.17", optional = true } | ||
futures-io = { version = "=0.3.17", optional = true } | ||
futures-sink = { version = "=0.3.17", optional = true } | ||
futures-util = { version = "=0.3.17", optional = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, we don't need to pin, and this is a good opportunity to drop most of the deps here - both here and in lightning-block-sync
we can replace futures with futures-util = { version = "0.3", default-features = false }
, which seems to build on 1.41 for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, are you sure you didn't somehow still enable the default features locally (namely std
and async-await-macro
, which depends on futures-macros
)? I can't reproduce that it works without, especially since select
and Mutex
seem to be only re-exported when they are set, e.g.:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also note that unpinning, i.e., version = "0.3"
(abb55fd), leads to version 0.3.24 being used, which fails on 1.41.1. This was the reason I had to pin in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, indeed, my test was bunk. A few things: (a) I think we should keep default-features = false
, just use the async-await-macro
feature, and swap to select_biased
(which shouldn't matter for us, and its actually strictly less code - select
just adds a random shuffle), (b) I think we should just bump the MSRV for lightning-background-processor/futures to 1.45.2, with block-sync and net-tokio.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, now went this way with 19ae0b6.
Unfortunately, default-features = false
doesn't work for lightning-block-sync
though, since Mutex
also requires std
: https://github.com/rust-lang/futures-rs/blob/7a98cf0bbeb397dcfaf5f020b371ab9e836d33d4/futures-util/src/lock/mod.rs#L15-L18
1e792a9
to
abb55fd
Compare
0880c89
to
19ae0b6
Compare
Still unsure why two jobs are pending "status to be reported", as they seem to have finished just fine? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please squash. The "missing runs" thing I think is just cause the definition of the jobs changed so Github is sad. We'll have to temporarily disable requiring those jobs to merge but that's fine.
Needs rebase. |
9957d3a
to
8e93bd4
Compare
Rebased and squashed changes addressing latest comments. |
select! { | ||
select_biased! { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to have the reason for this change in the commit message or in a separate commit if unrelated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added more context in commit message with 0038a3f. Let me know if it is sufficient.
This adds testing of the `futures` feature to CI. In order to avoid introducing a dependency on `std`, we switch to using the `futures-util` crate directly enabling only a subset of features. To this end, we also switch to using the `select_biased!` macro, which is equivalent to `select!` except that it doesn't choose ready futures pseudo-randomly at runtime.
8e93bd4
to
0038a3f
Compare
Fixes #1739.
This updates the docs so that they build with the
futures
feature enabled.