State of release

[ajpauwels]

Hey all, would it be possible to cut a release at the current master commit level or similar? As long as it's post #111 that should work.

Coming in as a new user I was confused between the differing formats in the examples source and in the docs. It didn't help that the examples source (which is the correct way to do things) doesn't compile with the latest version of the crate. Once the dependency is renamed to lambda = { git = "https://github.com/awslabs/aws-lambda-rust-runtime/", branch = "master" } everything works for the new syntax.

I can try and provide documentation and examples improvements PRs but if the maintainers could cut a release I think that'd go a long way to usability.

[outkine]

Can confirm that using the lambda_runtime dependency (as directed by the README) does not compile because of an issue with an old version of the time library:

error: expected an item keyword
   --> .../time-0.2.8/src/utc_offset.rs:366:13
    |
366 |             let tm = timestamp_to_tm(datetime.timestamp())?;
    |             ^^^

[softprops]

unfortunately the readme has gone stale. I can help with this.

You should only need the lambda crate for basic use. This crate simplified the previous versions and brought support for async/await into the fold. There is some inflight work to bring the lambda-http crate up to speed with the new lambda crate interfaces.

At this point you might be best served by using the examples here adapting the packaging and deployment notes from the readme.

Let us know if you get stuck.

[Luminoth]

Are there plans to cut a new release tho? Or should we plan to keep using the github dependency for a while still?

I'm also curious when the hello-with-ctx example is going to be expanded on. It isn't super clear to me how that's supposed to work with the macro-based implementation and the example is just copy / paste the hello example right now. Everything else seems more or less clear from the examples and a little bit of trial and error (for instance the examples deal with serde Values for input / output but really they just need to derive the serde traits).

I guess one other question I personally have is - can this be used with proxy API gateways?

[mickdekkers]

@Luminoth I'm not sure how the context is meant to be accessed, but this seems to work:

use lambda::{lambda, INVOCATION_CTX};
use serde_json::Value;

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[lambda]
#[tokio::main]
async fn main(event: Value) -> Result<(), Error> {
    INVOCATION_CTX.with(|ctx| {
        println!("Context is {:#?}", ctx);
    });
    println!("Event is {:#?}", event);
    Ok(())
}

Here INVOCATION_CTX is a tokio::task::LocalKey<lambda::types::LambdaCtx>.

The downside of this approach is that the context is only available in the closure you pass to with. LocalKey also has a get method but this can't be used at the moment since LambdaCtx doesn't impl Copy (and would also be a bit wasteful, since it would copy LambdaCtx).

Note: I tested this with the latest revision, ebc5474 as of this writing.

[drusellers]

Coming in as a new user I was confused between the differing formats in the examples source and in the docs. It didn't help that the examples source (which is the correct way to do things) doesn't compile with the latest version of the crate. Once the dependency is renamed to lambda = { git = "https://github.com/awslabs/aws-lambda-rust-runtime/", branch = "master" } everything works for the new syntax.

Yup. Definitely lost a day with this. Looking forward to a new release. Also, happy to help with docs, if for no other reason than to help future me. :)

[mlafeldt]

I also noticed that there's no git tag/release for the latest crate version (v0.2.1).

[algermissen]

Hi, I am also struggling with this - any news? Has this maybe been abandoned? Or moved to a different repo?

[softprops]

I feel the struggle. What are the current blockers to publishing a new release now that the http crate is in line with the new "core" crate?

[davidbarsky]

Not abandoned; I'm just short on time. I'm in the process of getting the Lambda runtime team to assign headcount/staff to this runtime—not sure when that will happen, but that would give this library some better stewardship and maintainership than I can currently afford to.

I feel the struggle. What are the current blockers to publishing a new release now that the http crate is in line with the new "core" crate?

Docs, I think? I'd like to give them a once-over before we cut a beta.

[softprops]

@davidbarsky few other notes.

I'm prepping for some new releases of packaged workflows for serverless rust plugin and am trying to get official support for aws sam through the pipeline. I've been updating a bunch of getting templates to reference master in prep for a forth coming release. This made me think about a few things we might want before cutting a release

1. An updated readme! It's been noted a few times that there's some confusion around the readme examples and what everyone's been talking about with async support. It might be helpful to do a readme refresher.

2. possibly add a migration doc. The transition as been pretty straight forward for me so far. In the most basic case, the transition looks something like this.

[dependencies]
- lambda_runtime = "0.2"
+ tokio = { version = "0.2", features = ["macros"] }
+ lambda = { git = "https://github.com/awslabs/aws-lambda-rust-runtime/", branch = "master"}

-use lambda_runtime::{error::HandlerError, lambda, Context};
+use lambda::handler_fn;
use serde_json::Value;

-fn main() {
-    lambda!(handler)
+type Error = Box<dyn std::error::Error + Sync + Send + 'static>;

+#[tokio::main]
+async fn main() -> Result<(), Error> {
    lambda::run(handler_fn(handler)).await?;
    Ok(())
}

-fn handler(
-    event: Value,
-    _: Context,
-) -> Result<Value, HandlerError> {
+async fn handler(event: Value) -> Result<Value, Error> {
    Ok(event)
}

3. possibly provide aggregator crate, like tokio. I think you mentioned this in http crate update but it might be helpful to have one lambda crate with a core (currently what's in lambda) and a http crate. Allowing users to opt into features and http and in the future others with a cargo feature flag vs keeping track of different crates. This doesn't feel like a blocker to me and good be a follow up but I wanted to keep the idea floating in the air.

4. another bonus idea I'd like to though out is a lambda (md?) book, similar to what you see in -other other ambitious projects. This provides a bit more space for a guided narrative than is afforded in the real estate available in a readme.

[softprops]

Oh also and a finalized lambda context api. I feel like there's some room for improvement there

[Veetaha]

@davidbarsky @softprops
Hey guys, this is quite disappointing that there hasn't been a release for a year. If documentation is all that it takes to cut a release, would you review and accept a PR from anyone to write it out (README, examples, api docs, etc.)?

[softprops]

I hear you.

I don't think I have of merge permissions but I'm happy to take a look. api docs and and examples on master should reflect the state of current code. What is ultimately going to be useful is a helpful changelog entry for what changed which is alot. A second in the README for unrelated but upcoming changes would also be good. The good news is this current version has a much smaller surface area to cover.

I'm going to take a stab at the trying to find a slightly nicer context api.

[davidbarsky]

I'm sorry for the frustration. I've been working on a release blog post for the new changes, which will include an updated README.md.