Lambda layer updating when there were no changes

Why does chalice with automatic_layer have to update the lambda layers every time you call deploy? If it knows to use the same deployment package, shouldn’t it know it doesn’t need to update the layer? This method doesn’t really save time like it says in the documentation, because the dependencies are still getting re-deployed.

Example where I run deploy twice:

$ chalice deploy
Creating shared layer deployment package.
Creating app deployment package.
Creating lambda layer: webstack-dev-managed-layer
...
$ chalice deploy
Creating shared layer deployment package.
  Reusing existing shared layer deployment package.
Creating app deployment package.
  Reusing existing app deployment package.
Updating lambda layer: webstack-dev-managed-layer
...

[res0nat0r]

Also I believe this breaks the shared layers concept outlined in the AWS blog post here.

IE, trying to set a fixed shared layer like so:

{
  "version": "2.0",
  "app_name": "reuse-layer",
  "layers": ["arn:aws:lambda:us-west-2:12345:layer:layerapp-dev-managed-layer:2"],
  "stages": {
    "dev": {
      "api_gateway_stage": "api"
    }
  }
}

Will break upon two subsequent deployments of the same requirements.txt, even though the actual requirements don’t change. Since the :version number will get bumped and the previous version deleted, all of the layer sharing will break, even though the actual layer contents haven’t been modified, so you can’t really point to an 100% known fixed shared layer which you know contains these exact package versions and these versions only, since the version number isn’t fixed.

[jamesls]

Yeah, it seems like that’s an optimization we should be able to make. The main benefits you get now are 1) skipping the pip download process and 2) sharing the layer across multiple lambda functions, but if you just have a single lambda function it really only saves time by skipping the pip download process.