We recently tried to upgrade/catch up from Pants 2.17.0 -> 2.21.0 and I noticed that our Azure Function broke. The only thing we changed was the Pants version in

pants.toml

. We package our code as a PEX and zip-deploy to Azure. Our

pex_binary

target looks like this:

resource(name="function-app-config", source="host.json")

pex_binary(
    name="az-function",
    output_path="az-function.zip",
    dependencies=[
        "//:function-app-config",
        "my_function:AzureFunction",
    ],
    tags=["package"],
)

The error reported by Azure:

Result: Failure Exception: FunctionLoadError: cannot load the my_function function: type of 
event binding in function.json "eventGridTrigger" does not match its Python annotation "EventGridEvent" 
Stack: File "/azure-functions-host/workers/python/3.10/LINUX/X64/azure_functions_worker/dispatcher.py", 
line 485, in _handle__function_load_request 
self._functions.add_function( File "/azure-functions-host/workers/python/3.10/LINUX/X64/azure_functions_worker/functions.py", 
line 392, in add_function input_types, output_types, _ = self.validate_function_params( File "/azure-functions-host/workers/python/3.10/LINUX/X64/azure_functions_worker/functions.py", 
line 251, in validate_function_params raise FunctionLoadError(  # azure truncated it here...

As I mentioned earlier we changed nothing in the code or the function configuration--just the Pants version. Reverting the Pants upgrade returned the AF to working order. The PEXes produced by each version contain slightly different files in the deps and bootstrap directories, but the root containing our source is identical. Have there been any changes to the way PEXes are structured that could be related?

Not sure about what might be related changes, but could you try incrementing versions one version at a time? 2.17.0 -> 2.18.0 -> 2.19.0 ... etc. Would help pinpoint where the error is introduced. (and someone more knowledgeable than myself can take over from there haha)

I’ll try to find some time to do this. Unfortunately, it’s not easily testable without going through the full build and deploy process which is fairly time consuming.

I understand that. Since its a fairly large version gap, you might be able to binary search it. Try 2.19 first,and then see if 2.18 or 2.20 comes next 🙂

Good idea!

One little tricklet (that may or may not work) is to increment version by version and to run

pants peek

for each version (you'll need to sort the output), then compare version to version. Flagrant errors usually pop up pretty quick.

Here’s the diff of the contents of the PEXes w/ 2.17 on the left and 2.21 on the right. I removed our internal code, but that was unchanged. Most of the differences are with setuptools and

.bootstrap

files. I’ll take a look at peek this afternoon.

I've never used an Azure function, so it's hard for me to say - I'm just suggesting to

pants peek

your repo to see if there are changes, and if any of those might be relevant

The only difference between

pants peek

output for the target defining the Function App is the new

goals

field.

There were some changes to FaaS functionality in those versions, with deprecations, so upgrading version by version may show you relevant deprecation messages

We’re not using any FaaS functionality provided by Pants which only extends to AWS Lambda and GCF and not Azure Functions as far as I’m aware. We’re just building a

pex_binary

using the target shown in my earlier comment and using

az function

to zip deploy the PEX. I built test PEXes containing the minimum code required for an event triggered Function (see example for v1 Python programming model here) with each version of Pants from 2.17-2.21 and zip deployed them to Azure Functions. The PEXes generated starting with v2.20 throw the above error when the Function is triggered. I’ve attached the PEXes in case they may be of use in investigating the cause. The v2.20 change log mentions some changes to the pex tool, but none seem like they should affect this use case. No deprecation warnings/messages were shown during this process.

Necro-ing this thread rather than distracting from the related https://pantsbuild.slack.com/archives/C046T6T9U/p1736813197867259 I don't know anything about Azure Functions, but there's a chance the output of the AWS Lambda targets (or GCF) could also work in Azure Functions. It may also not be too hard to add support for Azure functions specifically (depending on the expected zipfile structure). In particular the

python_aws_lambda_function

target outputs a zip containing both first-party and third-party code at the top level. The AWS-specific stuff is the name and some smarts around choosing the right version of platform-specific dependencies, so this might have to use "complete platforms". In particular, all the pex smarts/overhead are executed and evaporated at build time. Is there a chance you've tried either of them?

Is there a chance you’ve tried either of them?

I haven’t yet. I’ll take a look.