Upgrade to tokio 1.0 #142

dnaka91 · 2020-12-24T02:22:57Z

Tokio 1.0 has just been released and PR updates to the latest release.

This depends on:

Update to bytes 1.0 tungstenite-rs#163 to be merged first which upgrades tungstenite to use bytes to 1.0.
https://github.com/tokio-rs/tls to be released first which upgrades tokio-native-tls to use tokio 1.0.

I will update this PR as the dependencies become ready.

Currently waiting on new release of the following crates to mark this PR as ready:

hansihe · 2020-12-30T18:52:12Z

Now that tokio has reached 1.0, I think it would make sense to specify the dependency with a caret ^1.0.0 instead of exact like done in the PR?

This is especially important since 1.0.1 has already been released.

Also, is there any timetime on a release, and is there anything I can do to help out?

paolobarbolini · 2020-12-30T18:54:52Z

Now that tokio has reached 1.0, I think it would make sense to specify the dependency with a caret ^1.0.0 instead of exact like done in the PR?

It's the same thing

hansihe · 2020-12-30T19:01:57Z

It's the same thing

Ah, TIL, thanks!

aknuds1

The tungstenite-rs dependency needs updating, since nickelc's branch was merged into snapview and then removed.

Cargo.toml

CI fails due to: snapview/tokio-tungstenite#142 (comment)

* feat(providers): tokio 1.0 BREAKING: This removes async-std as a compatibility option * feat: tokio 1.0 in rest of crates * fix: patch Cargo.toml until deps are released * fix(contract): load ws deps * feat: bytes 1.0 (#121) * feat(core): move to bytes::Bytes * feat: adjust rest of crates to Bytes * chore: bump deps CI fails due to: snapview/tokio-tungstenite#142 (comment) * chore: use latest tokio-tungstenite * ci: split tests into jobs (#129) * Switch to `hex` (#128) * fix(core): replace rustc_hex with hex * fix(providers): replace rustc_hex with hex * chore: replace rustc-hex with hex * chore: cargo fmt * fix(ledger): copy address from string correctly * chore: fix flaky tests Fixes #105

coolreader18 · 2021-01-04T03:25:27Z

Is there anything that's still blocking this?

dnaka91 · 2021-01-04T05:01:48Z

@coolreader18 currently just waiting for the tungstenite and input_buffer crates to release a new version.

This is due to input_buffer having a dependency on bytes 0.5 and the new tokio depends on 1.0.

Technically this could be merged and released (removing the current git reference for the tungstenite dependency). That would cause crates to build with bytes 0.5 AND 1.0 as this crate would still use the current input_buffee with 0.5 and tokio would use 1.0. that is okay because input_buffer only uses it internally but bloats the library and it's always good to avoid compiling in multiple versions of the same crate.

In the end it's up to the guys from snapview. Either release new versions of input_buffer and tungstenite first and then merge this, or merge now and do the upgrade of tungstenite later (eventually even before the next release).

So far I was just planning to keep this as draft until the new versions are out.

strohel · 2021-01-04T10:51:42Z

Hi @dnaka91 and others, thanks for all the work!

Let's see if we can release input_buffer and tungstenite soon so that this can reference released versions.

ry · 2021-01-07T11:02:19Z

Thanks for this work!

In Deno, tokio-tungstenite is the last dependency we are waiting on to upgrade to Tokio 1.0. Happy to lend a hand if there's any specific work needed but it sounds like you all are just waiting on input_buffer tho?

dnaka91 · 2021-01-07T12:39:43Z

Hi @ry, yeah just waiting for the releases of input_buffer and tungstenite, that's all. I added them to the PR description so people can see what is currently missing for this to be ready for merging.

extrawurst · 2021-01-07T12:47:39Z

input_buffer changed its dependency already 9days ago, it is just not released yet: snapview/input_buffer#5

Owez · 2021-01-08T00:56:32Z

I've asked about tungstenite-rs as there currently aren't any issues/prs I can see unless they where hidden in a unreleased commit somewhere: snapview/tungstenite-rs#169 (not a contrib to tokio-tungstenite or tungstenite-rs myself, just a user of warp)

dnaka91 · 2021-01-08T01:19:09Z

inbut_buffer 0.4 was released today (https://crates.io/crates/input_buffer/0.4.0). Now just waiting on the tungstenite-rs release. Thanks for opening an issue to push things @Owez 🙇

dnaka91 · 2021-01-08T12:32:51Z

Thank you for the release of tungstenite 0.12 and quick update of the dependency here @application-developer-DA 🙇
Guess we're ready for merge then.

strohel

The code looks good to me. I'd appreciate somebody else also has a look at the changes in examples/interval-server.rs as I'm not proficient with https://docs.rs/tokio/1.0.1/tokio/macro.select.html

udoprog · 2021-01-08T14:28:47Z

The code looks good to me. I'd appreciate somebody else also has a look at the changes in examples/interval-server.rs as I'm not proficient with https://docs.rs/tokio/1.0.1/tokio/macro.select.html

FWIW. I can confirm that the use of tokio::select! in interval-server.rs looks correct.

ranile · 2021-01-08T12:55:45Z

Cargo.toml

@@ -21,10 +21,10 @@ stream = []
 log = "0.4"
 futures-util = { version = "0.3", default-features = false, features = ["async-await", "sink", "std"] }
 pin-project = "1.0"
-tokio = { version = "0.3", default-features = false, features = ["io-util"] }
+tokio = { version = "1.0.0", default-features = false, features = ["io-util"] }


Is there any reason for pinning to 1.0.0. Why can't it just be 1.0?

If semantic versioning is used properly for this, which it should be, couldn't this even be "1" as tokio is stable on 1.x.x?

That's a valid point. I mostly also specify the minor version in my apps so i didn't think of that. So, the tokio version here should just be 1

Right, per https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements 1, 1.0 and 1.0.0 are all equivalent.

Then it is a question of style/consistency. 1.0 would be most consistent locally (see line above). Is anybody aware of an ecosystem-wide style recommendation for equivalent version declarations in Cargo.toml?

All I remember is Cargo endorses semantic versioning and the major version thats 1+.x.x won't have any breaking changes. It's fine to use 1.0 as well for consistency and in case of local bugfixes that get added/removed due to tokio in this repo as tokio is developed/patched

As @strohel mentioned 1.0.0 is equivalent to 1.x.x. the only exception to this rule are 0.x.x releases. For example 0.1.0 would be equivalent to 0.1.x.

I personally prefer the full version as it kind of is a statement to what version the project was tested with by the authors and considered to be working. So that later when an error happens only on the user side and the user states that he is using for example the auto upgraded 1.5.3 instead of 1.0.0, then it's easy to derive that the error lies in some changes of the said dependency. Or at least would be likely and a good thing to look at first.

In the end it's up to you folks from snapview. I just wanted to explain my reasoning behind putting the full version in the Cargo.toml and don't mind changing to just 1.0 or 1.

It's not pinned, this is equivalent to ^1.0.0 (docs) and will allow updates to any 1.x.x.

It's not pinned, this is equivalent to ^1.0.0 (docs) and will allow updates to any 1.x.x.

TIL. Thanks for informing me

* feat(providers): tokio 1.0 BREAKING: This removes async-std as a compatibility option * feat: tokio 1.0 in rest of crates * fix: patch Cargo.toml until deps are released * fix(contract): load ws deps * feat: bytes 1.0 (#121) * feat(core): move to bytes::Bytes * feat: adjust rest of crates to Bytes * chore: bump deps CI fails due to: snapview/tokio-tungstenite#142 (comment) * chore: use latest tokio-tungstenite * ci: split tests into jobs (#129) * Switch to `hex` (#128) * fix(core): replace rustc_hex with hex * fix(providers): replace rustc_hex with hex * chore: replace rustc-hex with hex * chore: cargo fmt * fix(ledger): copy address from string correctly * chore: fix flaky tests Fixes #105

dnaka91 added 2 commits December 24, 2020 11:18

Upgrade to tokio 1.0

7e1ac6c

Fix formatting in handshake.rs

9c05f20

sdroege mentioned this pull request Dec 24, 2020

WIP: Upgrade to tokio 1.0 #143

Closed

Update to tokio-native-tls 0.3.0

0f0665b

dovahcrow mentioned this pull request Dec 25, 2020

Upgrade tokio to 1.0 dovahcrow/bitmex-rs#22

Closed

3 tasks

yos1p mentioned this pull request Dec 26, 2020

upgrade: tokio 0.1 in test_util crate denoland/deno#8885

Merged

msrd0 mentioned this pull request Dec 28, 2020

Update hyper to 0.14 and tokio/bytes to 1.0 gotham-rs/gotham#511

Merged

sdroege mentioned this pull request Dec 29, 2020

Tokio 1.0.0 #145

Closed

caass mentioned this pull request Dec 29, 2020

upgrade: tokio 1.0 denoland/deno#8779

Merged

gakonst mentioned this pull request Dec 30, 2020

Upgrade to Tokio 1.0 and remove async-std gakonst/ethers-rs#120

Merged

aknuds1 suggested changes Dec 31, 2020

View reviewed changes

Cargo.toml Outdated Show resolved Hide resolved

gakonst added a commit to gakonst/ethers-rs that referenced this pull request Dec 31, 2020

chore: bump deps

96d53f1

CI fails due to: snapview/tokio-tungstenite#142 (comment)

Update tungstenite dependency to main repo

078a227

aknuds1 approved these changes Dec 31, 2020

View reviewed changes

d-e-s-o mentioned this pull request Dec 31, 2020

Old version of tokio d-e-s-o/apca#1

Closed

gakonst added a commit to gakonst/ethers-rs that referenced this pull request Dec 31, 2020

chore: bump deps

34b6222

CI fails due to: snapview/tokio-tungstenite#142 (comment)

gakonst added a commit to gakonst/ethers-rs that referenced this pull request Dec 31, 2020

chore: bump deps

e0da62a

CI fails due to: snapview/tokio-tungstenite#142 (comment)

thomaseizinger mentioned this pull request Jan 4, 2021

Upgrade to tokio 1.0 comit-network/waves#82

Merged

4 tasks

FelipeRosa mentioned this pull request Jan 5, 2021

Publish to crates.io FelipeRosa/jason-rs#12

Closed

2 tasks

rakshith-ravi mentioned this pull request Jan 5, 2021

Switch over to Tokio ecosystem trunk-rs/trunk#105

Closed

2 tasks

simonsan mentioned this pull request Jan 7, 2021

Upgrade to Tokio v1 seanmonstar/warp#725

Closed

3 tasks

Update to upstream version of tungstenite

c0e4979

daniel-abramov marked this pull request as ready for review January 8, 2021 12:27

strohel approved these changes Jan 8, 2021

View reviewed changes

strohel requested review from daniel-abramov and jxs January 8, 2021 14:22

ranile reviewed Jan 8, 2021

View reviewed changes

nightkr mentioned this pull request Jan 8, 2021

Test ws features on Circle CI kube-rs/kube#378

Closed

jxs approved these changes Jan 8, 2021

View reviewed changes

dnaka91 mentioned this pull request Jan 9, 2021

Add support for rustls as TLS backend, update tungstenite version #147

Merged

daniel-abramov approved these changes Jan 9, 2021

View reviewed changes

daniel-abramov merged commit d3ae6c6 into snapview:master Jan 9, 2021

dnaka91 deleted the tokio-1.0 branch January 9, 2021 16:21

jjeffcaii mentioned this pull request Jan 11, 2021

Upgrade to Tokio 1.0 rsocket/rsocket-rust#33

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade to tokio 1.0 #142

Upgrade to tokio 1.0 #142

dnaka91 commented Dec 24, 2020 •

edited by daniel-abramov

Loading

hansihe commented Dec 30, 2020

paolobarbolini commented Dec 30, 2020

hansihe commented Dec 30, 2020

aknuds1 left a comment

coolreader18 commented Jan 4, 2021

dnaka91 commented Jan 4, 2021

strohel commented Jan 4, 2021

ry commented Jan 7, 2021

dnaka91 commented Jan 7, 2021

extrawurst commented Jan 7, 2021

Owez commented Jan 8, 2021 •

edited

Loading

dnaka91 commented Jan 8, 2021

dnaka91 commented Jan 8, 2021

strohel left a comment

udoprog commented Jan 8, 2021 •

edited

Loading

ranile Jan 8, 2021

Owez Jan 8, 2021

ranile Jan 8, 2021

strohel Jan 8, 2021

Owez Jan 8, 2021

dnaka91 Jan 8, 2021 •

edited

Loading

lukesteensen Jan 8, 2021

ranile Jan 8, 2021

Upgrade to tokio 1.0 #142

Upgrade to tokio 1.0 #142

Conversation

dnaka91 commented Dec 24, 2020 • edited by daniel-abramov Loading

hansihe commented Dec 30, 2020

paolobarbolini commented Dec 30, 2020

hansihe commented Dec 30, 2020

aknuds1 left a comment

Choose a reason for hiding this comment

coolreader18 commented Jan 4, 2021

dnaka91 commented Jan 4, 2021

strohel commented Jan 4, 2021

ry commented Jan 7, 2021

dnaka91 commented Jan 7, 2021

extrawurst commented Jan 7, 2021

Owez commented Jan 8, 2021 • edited Loading

dnaka91 commented Jan 8, 2021

dnaka91 commented Jan 8, 2021

strohel left a comment

Choose a reason for hiding this comment

udoprog commented Jan 8, 2021 • edited Loading

ranile Jan 8, 2021

Choose a reason for hiding this comment

Owez Jan 8, 2021

Choose a reason for hiding this comment

ranile Jan 8, 2021

Choose a reason for hiding this comment

strohel Jan 8, 2021

Choose a reason for hiding this comment

Owez Jan 8, 2021

Choose a reason for hiding this comment

dnaka91 Jan 8, 2021 • edited Loading

Choose a reason for hiding this comment

lukesteensen Jan 8, 2021

Choose a reason for hiding this comment

ranile Jan 8, 2021

Choose a reason for hiding this comment

dnaka91 commented Dec 24, 2020 •

edited by daniel-abramov

Loading

Owez commented Jan 8, 2021 •

edited

Loading

udoprog commented Jan 8, 2021 •

edited

Loading

dnaka91 Jan 8, 2021 •

edited

Loading