migrate to futures-0.3

[danieleades]

Any plans to move to a futures-0.3 API?

This would allow easy interop with the async/await syntax.

The downside of course is that it's not quite stabilised, so could only target nightly.

Hyper has just about finished migrating, but even before that shiplift can start returning std::futures using the compat layer.

[softprops]

Thanks for posting. I haven't taken a specific look yet. I'm aware that things are changing. I'm was planning on waiting until interfaces stabilize to minimize the amount of breaking changes I'd have to make in these interface. Once hyper is finished this crate mostly gets the upgrade for free.

[danieleades]

fair enough. Just to clarify, while async/await syntax is not stabilised yet, std::future is stabilised. Meaning that the interface is already stable.

I agree that it's probably worth waiting. async/await will probably lead to a bit of a refactor too- it's not just a new syntax, it also adds some handy borrowing semantics for futures, so you don't need to clone objects and pipe them through multiple futures anymore

https://github.com/rust-lang/rust/labels/AsyncAwait-Blocking

rust-lang/rust#62149

[danieleades]

I've started playing around with this in the above pull request. The upgrade is a hell of a long way from 'free', turns out.

The async await syntax simplifies a lot of methods which return futures, which is nice. Doesn't do so much to simplify the methods which return streams (there's no equivalent syntax for streams as yet).

[vincent-163]

Now that async/await syntax is stabilized and hyper supports futures-0.3, what is the latest progress on this issue?

The async await syntax simplifies a lot of methods which return futures, which is nice. Doesn't do so much to simplify the methods which return streams (there's no equivalent syntax for streams as yet).

The current way to iterate through a stream in an async function looks like:

while let Some(item) = stream.next().await? {
   // async processing
}

[thomaseizinger]

Now that async/await syntax is stabilized and hyper supports futures-0.3, what is the latest progress on this issue?

@vincent-163 There is this open PR: #191

[danieleades]

@vincent-163

The current way to iterate through a stream in an async function looks like:

what you don't get is lifetime elision. you also need to wrap any stream manipulation functions in async blocks. async closures are not yet supported. Additionally, at the time this issue was opened tokio and futures had different Stream implementations. Hyper was using tokio, but futures was the only library that had stream combinators compatible with futures 0.3. as of a few weeks ago, tokio is now re-exporting futures::Stream, so we're in a better place. I expect the same thing to happen with AsyncWrite and AsyncRead soon.

also, i think the syntax you're looking for is

while let Some(item) = stream.next().await {
   let item = item?;
   // async processing
}

also, first you have to pin it to the stack, and then you have to wrap it in an async block, and then you have to write out explicit lifetimes in your return types. And you'll end up adding map_err(Error::from).try_flatten_stream() in most of your function bodies.
It's not too bad, but there's a way to go before the streams syntax reaches parity with the futures syntax.

I'm no longer working on this- but the pull request above is largely complete if anyone's looking to pick it up. My refactoring got a bit drastic, and out of scope of the pull request, so I gave it up. Working slowly on a new docker client with my proposed syntax, and async-await support. will post here when i have an update. I think the best way forward for shiplift is to branch off master into an async-await branch and start accepting pull requests for the refactor. I think it's far too big a change for a single pull request.

[danieleades]

i'm revisiting this, given i've got a tiny bit of extra time on my hands during the lockdown...

https://github.com/danieleades/longshoreman

given the sheer volume of endpoints to cover, i'm absolutely looking for feedback on which ones people need, and for pull requests to add them.
My hope is that by centralising the logic for handling requests and responses, it should be relatively straightforward for contributors to implement endpoints incrementally!

The core logic of the HTTP client is implemented, and uses the latest Hyper, async/await, etc.
The endpoints use (/will use) a builder API for constructing requests. All requests and responses are strongly-typed.

[whizsid]

I am currently managing my dockers with std::process::Command and I would like to migrate to shiplift. But my tokio future version and the shiplift future version are not matching.

[danieleades]

@whizsid step into my office

I'm adding things incrementally. If you can tell me what you need, I'll prioritise adding that next.

[whizsid]

@danieleades Thank you! But your crate is not fully developed. I want to manage volumes and execute some commands in my containers.

[danieleades]

@danieleades Thank you! But your crate is not fully developed. I want to manage volumes and execute some commands in my containers.

It's far from fully developed, but if you can tell me what you need implemented, I can make sure that gets added next!

Alternatively, you can use this crate with a compat layer.