unresolved import `lambda_attributes` when compiling with default-features = false

[mikeyhew]

If I use this crate without any defualt features enabled, it fails to compile because something from the lambda_attributes crate is imported, even though it isn't a dependency in Cargo.toml. It should be a simple fix - just add a #[cfg(feature = "lambda-attributes")] above the import, and maybe in a few other places.

In order to avoid regressions in the future, we could update the hello-no-macro example to use the lambda crate without any default features, so that it fails to compile if this breaks again (and hopefully causes CI to fail).

To reproduce, use this in your Cargo.toml file:

lambda = { git = "https://github.com/awslabs/aws-lambda-rust-runtime", default-features = false}

[davidbarsky]

Thanks for reporting this, and you're right that this is an issue. More broadly, I'm unhappy with lambda-attributes and I'd like to remove it for two reasons:

• The compiler errors people get from it are bad.
• Due to how cold/warm starts work on Lambda, the naive approach of setting up resources (such as loggers) within a #[lambda]-decorated block will cause the logger initializer to panic in a warm start. That's not great.

What do you think?

[softprops]

I feel like it's still useful. It's just a matter of documentation https://awslabs.github.io/aws-lambda-rust-runtime/lambda_http/#hello-world-without-macros

[mikeyhew]

I wouldn't be opposed to that. There's a lot of work involved in building the actual function for the x86_64-unknown-linux-musl target, setting up the appropriate roles and permissions, and creating the function on AWS; and the ~5 lines of code that the macro saves you isn't really a whole lot in the grand scheme of things.

I actually did try using it at first, but as soon as I saw the error message issue, I got rid of it. The reason I wanted to disable it with default-features = false is because it requires on an old version of proc-macro2 that I didn't want to add to my Cargo.lock.

One suggestion: you could always move it out to a separate crate, and have someone else maintain it, at least for now until the error message issue is resolved.

[rimutaka]

The other negative of having 2 pathways is the initial confusion. It takes some time to understand the difference. Should I use main or macro? What are the pro's and con's? It would be less code to maintain too if we got rid of it.

[softprops]

Should I use main or macro? What are the pro's and con's?

See the docs linked above it specifically calls out when not to use it and the tradeoff of when you are using it

[davidbarsky]

See the docs linked above it specifically calls out when not to use it and the tradeoff of when you are using it

I think that the primary upside of the #[lambda] macro is that "it looks nice in a screenshot". However, the downsides are severe when used in a typical production setting.

The #[lambda] macro introduces a discontinuity for the customer as they learn this crate's API—they must graduate to the desugared lambda::run-based API in order to make their Lambda function(s) operationally ready by introducing logging, metrics, and distributed tracing. Worse, the customer might not discover the downsides of the #[lambda] API until they've deployed their application to production and are seeing warm invocations. I'd rather remove this API than risk impacting people's production stages.

[miere]

That’s absolute spot on, @davidbarsky. Having less lines gives the idea that it is so simple it might cover all the side effects.

[bahildebrand]

#282 removed the lambda attributes crate, so this issue can be closed.