This message was deleted.

You would need to either keep doing those

pip installs

from your CI environment, or else automatically invoke them from within your Pulumi program. This example is JavaScript and Azure deploying a .NET Function - but highlights some of the patterns that are likely to apply here: https://github.com/pulumi/examples/tree/master/azure-ts-appservice-devops

I'm not familiar with azure, but after looking at that example, the overall pattern is 1) convert the app code into a deployable artifact 2) run pulumi to update infra and use that new artifact Ideally that deployable artifact would be built deterministically and not reinvoke the update on a consecutive runs...

That's right. And this example is the first of the two options I refer to above. The second would be to script the

pip install

into your pulumi program instead of depending on some external build in your CI environment. Certainly if your build is not deterministic, this approach will lead to churn of deployed artifacts. There are more complex options you could consider even if you do have a non-deterministic build to only trigger rebuild of the artifact on changes to input sources - but that would be more involved.

Do you know off hand how pulumi decides whether an artifact has changed? Is it just some hashing of the file?

Yes -

pulumi.asset.FileArchive

and related asset resources will hash the contents and use that to decide whether to report a change that needs to be flowed into dependencies.

ok so avoid zip compression then...

I've written a few zippackers for zipapp purposes, which has very similar requirements to lambda. Using one of these with

FileAsset

or a modified version with

ArchiveAsset

should work. https://gist.github.com/astronouth7303/54ff9d6245a0efc80b0a8fd2f8cba500 (Unfortunately, I'm a pulumi newbie, so I have no idea how to integrate a build process into pulumi, or even if you should)