replace futures with futures-util

[mati865]

This slightly reduces depedency tree.

[la10736]

Seams that this change broke the msrv test 😢

We should go little bit deeper to understand what's happen and if is possible to leave the same msrv or we should bump it

[mati865]

The failure is unrelated. futures crate pulls in futures-util anyway, so the only thing that changes here is using code directly instead of reexport from futures. I'm pretty sure any PR would fail like that.

I don't know this test setup, but to me it looks like toolchain in version 1.83 has generated lockfile in version 4 (this is the new default), but version 4 is supported only by toolchains 1,78+.

[la10736]

The failure is unrelated. futures crate pulls in futures-util anyway, so the only thing that changes here is using code directly instead of reexport from futures. I'm pretty sure any PR would fail like that.

I don't know this test setup, but to me it looks like toolchain in version 1.83 has generated lockfile in version 4 (this is the new default), but version 4 is supported only by toolchains 1,78+.

Maybe you're right. Yesterday it was midnight and I was too tired to check msrv on main branch: I just trusted the weakly CI... But there is something wired here: the weakly CI was run 3 days ago and didn't find any issues.

Now I run again the CI on main to check if there is something new.

[la10736]

Now I run again the CI on main to check if there is something new.

Ok, now the CI is failed also in main in the same way. I guess that a new cargo hack version was released in these days.

I can merge this PR because the issue is un related

[la10736]

Thanks

LGTM

[mati865]

No worries, thanks for the quick response.

[mati865]

I don't know this test setup, but to me it looks like toolchain in version 1.83 has generated lockfile in version 4 (this is the new default), but version 4 is supported only by toolchains 1,78+.

I've made a quick look at I'm certain this is the case. Pinning the toolchain in MSRV job to anything lower than 1.83 will avoid the problem.

[la10736]

Yeah... But what I've discovered is that step don't do what is supposed to do .... It should run the single test with a specific version, but is not possible to do it with the current e2e test implementation Il giorno gio 5 dic 2024 alle ore 18:22 Mateusz Mikuła < ***@***.***> ha scritto:

…

I don't know this test setup, but to me it looks like toolchain in version 1.83 has generated lockfile in version 4 (this is the new default), but version 4 is supported only by toolchains 1,78+. I've made a quick look at I'm certain this is the case. Pinning the toolchain in MSRV job to anything lower than 1.83 will avoid the problem. — Reply to this email directly, view it on GitHub <#288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5Y34OSV3MWH2BRYVL2ALT2ECDTXAVCNFSM6AAAAABTBC64LKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRQHE3TANZZGM> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>