conda 26.9.4 pixi 0.82.1 virtualenv 21.14.12 pipx 1.18.7 pipenv 2026.10.2 PDM 2.29.4 Pex 2.105.1 cibuildwheel 4.3.5 manylinux and musllinux images 2026.10.26-1 pypa/gh-action-pypi-publish 1.14.3 python-build-standalone 20261026 Hatch 1.18.2 (2) pyenv 2.8.

Question

conda 26.9.4 pixi 0.82.1 virtualenv 21.14.12 pipx 1.18.7 pipenv 2026.10.2 PDM 2.29.4 Pex 2.105.1 cibuildwheel 4.3.5 manylinux and musllinux images 2026.10.26-1 pypa/gh-action-pypi-publish 1.14.3 python-build-standalone 20261026 Hatch 1.18.2 (2) pyenv 2.8.

Apurva Pathak 960

Note- AI Drafted question because there was a lot to cover.

Hi,

I have a Python application running as a Linux Azure Function App and I’m trying to understand the behaviour I’m seeing with Python packages after multiple deployments.

Current setup:

The application is a Linux Azure Function App.
Deployment is performed through Azure DevOps using an AzureFunctionApp task.
The application is deployed using a ZIP artifact.
Python dependencies are located under:

/home/site/wwwroot/.python_packages/lib/site-packages/

The ZIP artifact generated by the pipeline is always clean.
However, after multiple deployments, older package metadata appears to remain in site-packages.

For example, for aiohttp I currently see:

aiohttp/
aiohttp-3.10.11.dist-info/
aiohttp-3.13.5.dist-info/
aiohttp-3.14.5.dist-info/

There is only one actual package directory:

aiohttp/

but there are multiple .dist-info directories corresponding to different versions from previous deployments.

The older .dist-info directories do NOT exist in the current deployment ZIP, so they appear to have been left behind by previous deployments.

My questions are:

When Python executes:

import aiohttp

which version of aiohttp is actually loaded?

Given that there is only one aiohttp/ directory, does Python simply import the code from that directory regardless of how many aiohttp-x.x.x.dist-info directories exist?
Are the .dist-info directories involved in Python’s import resolution, or are they only package metadata?
Can having multiple stale .dist-info directories cause runtime issues?

For example, could they affect:

importlib.metadata.version(“aiohttp”)

pip

dependency/version checks

libraries which query installed package metadata?

Could the application ever identify the wrong aiohttp version because multiple .dist-info directories exist?
Is it safe to completely remove:

/home/site/wwwroot/.python_packages

and then immediately redeploy the clean application artifact?

Would deleting the complete .python_packages directory be preferable to manually identifying and removing individual stale package/version directories?
For preventing this in future deployments, would running the Azure Function from an immutable deployment package be preferable to repeatedly extracting/overlaying deployment files into wwwroot?

I’m also planning to verify what the running application is actually importing using:

python -c “import aiohttp; print(‘Version:’, aiohttp.version); print(‘Loaded from:’, aiohttp.file)”

I’m mainly trying to understand whether these multiple .dist-info directories are simply stale metadata that should be cleaned up, or whether they could actually cause Python to use/report an incorrect package version while

Rukmini 44,000 Reputation points Microsoft External Staff Moderator

2026-11-03T13:39:03.37+00:00
Hello @Apurva Pathak Hi, the stale .dist-info folders don't change which code gets imported, but they can change which version gets reported. Cleaning them up is the right move. Here are your questions in order.

1. Which aiohttp is actually loaded?import aiohttp uses only the aiohttp/ package directory, which Python finds by searching sys.path. .dist-info folders play no part in import resolution; they're metadata only. So the code you run is whatever is currently in site-packages/aiohttp/.

One caveat: if every deployment overlaid files instead of replacing the folder, aiohttp/ itself may contain leftover modules from older versions. These are files that existed in an older aiohttp release but not in 3.14.5, for example an old compiled .so extension. Normally nothing imports them, but it means the folder isn't guaranteed to be an exact copy of 3.14.5.

2. Can multiple .dist-info folders cause problems? Yes, for anything that reads package metadata:

importlib.metadata.version("aiohttp") returns the first matching .dist-info it finds. The order comes from the filesystem's directory listing and isn't guaranteed, so it can return 3.10.11 while the 3.14.5 code is running.

pip (pip list, pip show, pip check) may show duplicate entries or pick the wrong one. Its dependency checks can then pass or fail incorrectly.

Libraries that check versions at runtime through importlib.metadata or pkg_resources can make the wrong decision. Examples are plugins, compatibility shims and telemetry SDKs.

So yes, your app can report the wrong aiohttp version even while it runs the right code.

3. Is it safe to delete /home/site/wwwroot/.python_packages and redeploy? Yes. Deleting the whole folder is better than removing individual stale folders by hand: it's simpler, you can't miss leftovers inside aiohttp/ itself, and the redeploy recreates exactly what's in your clean ZIP. Two things to watch:

The function will fail its imports between the delete and the redeploy. Stop the app first, or use a deployment slot, then deploy and start it again.

Make sure your pipeline's ZIP really contains .python_packages/lib/site-packages, meaning it builds with pip install --target=".python_packages/lib/site-packages" -r requirements.txt. If you rely on remote build instead, the packages are rebuilt during deployment, which is also fine.

4. Preventing it in future Yes, running from an immutable package is the better approach. With Run From Package, the ZIP is mounted read-only as wwwroot and isn't extracted on top of the previous contents†. Nothing from earlier deployments can survive, and each deployment is an exact copy of your artifact.

In Azure DevOps, set the AzureFunctionApp task's deployment method to Run From Package rather than plain Zip Deploy, or set the app setting WEBSITE_RUN_FROM_PACKAGE=1†.

Remember that wwwroot becomes read-only, so the app can't write files there at runtime.

Leftovers like yours usually build up when the deployment method has changed over time, for example remote build at one point and a pre-built ZIP at another, or when packages were installed manually. Sticking to one method keeps things predictable.

5. Checking what's actually running Your command works, but use the double-underscore attributes. Ideally run it inside a function and log the output, because the Functions worker adds .python_packages/lib/site-packages to sys.path, and an SSH session may not:

import aiohttp, importlib.metadata as md, glob, os print("Code version :", aiohttp.__version__) print("Loaded from :", aiohttp.__file__) print("Metadata says:", md.version("aiohttp")) sp = os.path.dirname(os.path.dirname(aiohttp.__file__)) print("dist-info :", glob.glob(os.path.join(sp, "aiohttp-*.dist-info")))

After cleaning up, you should see one .dist-info folder, and __version__ should match md.version().

If both versions still differ after a clean Run From Package deployment, post the output of that snippet and your pipeline YAML for the deployment step, and we can look further.Hi, the stale .dist-info folders don't change which code gets imported, but they can change which version gets reported. Cleaning them up is the right move. Here are your questions in order.

1. Which aiohttp is actually loaded?import aiohttp uses only the aiohttp/ package directory, which Python finds by searching sys.path. .dist-info folders play no part in import resolution; they're metadata only. So the code you run is whatever is currently in site-packages/aiohttp/.

One caveat: if every deployment overlaid files instead of replacing the folder, aiohttp/ itself may contain leftover modules from older versions. These are files that existed in an older aiohttp release but not in 3.14.5, for example an old compiled .so extension. Normally nothing imports them, but it means the folder isn't guaranteed to be an exact copy of 3.14.5.

2. Can multiple .dist-info folders cause problems? Yes, for anything that reads package metadata:

importlib.metadata.version("aiohttp") returns the first matching .dist-info it finds. The order comes from the filesystem's directory listing and isn't guaranteed, so it can return 3.10.11 while the 3.14.5 code is running.

pip (pip list, pip show, pip check) may show duplicate entries or pick the wrong one. Its dependency checks can then pass or fail incorrectly.

Libraries that check versions at runtime through importlib.metadata or pkg_resources can make the wrong decision. Examples are plugins, compatibility shims and telemetry SDKs.

So yes, your app can report the wrong aiohttp version even while it runs the right code.

3. Is it safe to delete /home/site/wwwroot/.python_packages and redeploy? Yes. Deleting the whole folder is better than removing individual stale folders by hand: it's simpler, you can't miss leftovers inside aiohttp/ itself, and the redeploy recreates exactly what's in your clean ZIP. Two things to watch:

The function will fail its imports between the delete and the redeploy. Stop the app first, or use a deployment slot, then deploy and start it again.

Make sure your pipeline's ZIP really contains .python_packages/lib/site-packages, meaning it builds with pip install --target=".python_packages/lib/site-packages" -r requirements.txt. If you rely on remote build instead, the packages are rebuilt during deployment, which is also fine.

4. Preventing it in future Yes, running from an immutable package is the better approach. With Run From Package, the ZIP is mounted read-only as wwwroot and isn't extracted on top of the previous contents†. Nothing from earlier deployments can survive, and each deployment is an exact copy of your artifact.

In Azure DevOps, set the AzureFunctionApp task's deployment method to Run From Package rather than plain Zip Deploy, or set the app setting WEBSITE_RUN_FROM_PACKAGE=1†.

Remember that wwwroot becomes read-only, so the app can't write files there at runtime.

Leftovers like yours usually build up when the deployment method has changed over time, for example remote build at one point and a pre-built ZIP at another, or when packages were installed manually. Sticking to one method keeps things predictable.

5. Checking what's actually running Your command works, but use the double-underscore attributes. Ideally run it inside a function and log the output, because the Functions worker adds .python_packages/lib/site-packages to sys.path, and an SSH session may not:

import aiohttp, importlib.metadata as md, glob, os print("Code version :", aiohttp.__version__) print("Loaded from :", aiohttp.__file__) print("Metadata says:", md.version("aiohttp")) sp = os.path.dirname(os.path.dirname(aiohttp.__file__)) print("dist-info :", glob.glob(os.path.join(sp, "aiohttp-*.dist-info")))

After cleaning up, you should see one .dist-info folder, and __version__ should match md.version().

If both versions still differ after a clean Run From Package deployment, post the output of that snippet and your pipeline YAML for the deployment step, and we can look further.
Apurva Pathak 960 Reputation points

2026-11-03T14:13:49.9533333+00:00

@Rukmini Thanks for the detailed response!

If that's the case, then does the zip deployment not poses a very severe risk to the applications. Because, even if we ship the new version of app to the function app thinking that we're upgrading the packages but the under the hood users might still be being served with older version, and if a hacker comes around this scenario (i.e. getting response from an older package which has open exploited vulnerability) they can get in (if they can successfully exploit it).

If my assumption above is true then should MS not flag out a warning to whosoever using Zip deployments method to make them aware of this rather severe security flaw at least with Python.
Apurva Pathak 960 Reputation points

2026-11-03T17:12:26.0833333+00:00

Also, I wanted to flag a critical deployment gotcha regarding our upgrade from pydantic==1.10.26 (v1) to pydantic==2.14.1 (v2).

The Problem

If we do zip deployment an in-place copying the files in an existing environment, it does not clean up all old v1 files from the site-packages/pydantic directory.

Because Pydantic completely rewrote its core architecture in v2, these orphaned .py files from version 1.10.26 collide with the new package namespace. This results in broken imports, unexpected namespace collisions, and silent validation failures—even if the exact same code passes tests on a fresh local setup. Is this not an issue?

1 answer

Your answer

Apurva Pathak 960 Reputation points

2026-11-03T14:13:49.9533333+00:00

@Rukmini Thanks for the detailed response!

If that's the case, then does the zip deployment not poses a very severe risk to the applications. Because, even if we ship the new version of app to the function app thinking that we're upgrading the packages but the under the hood users might still be being served with older version, and if a hacker comes around this scenario (i.e. getting response from an older package which has open exploited vulnerability) they can get in (if they can successfully exploit it).

If my assumption above is true then should MS not flag out a warning to whosoever using Zip deployments method to make them aware of this rather severe security flaw at least with Python.
Apurva Pathak 960 Reputation points

2026-11-03T17:12:26.0833333+00:00

Also, I wanted to flag a critical deployment gotcha regarding our upgrade from pydantic==1.10.26 (v1) to pydantic==2.14.1 (v2).

The Problem

If we do zip deployment an in-place copying the files in an existing environment, it does not clean up all old v1 files from the site-packages/pydantic directory.

Because Pydantic completely rewrote its core architecture in v2, these orphaned .py files from version 1.10.26 collide with the new package namespace. This results in broken imports, unexpected namespace collisions, and silent validation failures—even if the exact same code passes tests on a fresh local setup. Is this not an issue?

Answer 1

Python imports the single discoverable aiohttp package directory; the stale .dist-info directories do not select which code is imported, but they can make metadata-based version reporting ambiguous and should be removed by rebuilding the complete .python_packages tree and redeploying it.

What Python loads

import aiohttp follows Python’s normal import resolution over sys.path. It loads the first matching module or package—here, the relevant aiohttp/__init__.py—without using aiohttp-*.dist-info to choose a version.^1^

The .dist-info directories describe installed distributions. Tools such as importlib.metadata discover and read them, but distribution names and import-package names do not necessarily have a one-to-one relationship.^2^ They commonly contain the version, dependency declarations, installed-file records, and entry points.^3^

Consequently:

The code under aiohttp/ determines the imported implementation.
aiohttp.__file__ identifies the code location.
aiohttp.__version__, if exposed by that release, is supplied by the imported code.
importlib.metadata.version("aiohttp") reads distribution metadata and does not prove which implementation was imported.
Duplicate metadata is not a supported multi-version installation model. Metadata discovery should not be assumed to select the newest version; the result can depend on discovery order.^4^
Therefore, pip, dependency checks, entry-point discovery, or libraries using package metadata can report or act on the wrong stale record even though import aiohttp loads the current code.

Use straight quotes and double underscores when checking the running environment:

python - <<'PY'
import aiohttp
from importlib import metadata

print("Module file:", aiohttp.__file__)
print("Code version:", getattr(aiohttp, "__version__", "<not exposed>"))
print("Metadata version:", metadata.version("aiohttp"))

for dist in metadata.distributions():
    if (dist.metadata.get("Name") or "").lower() == "aiohttp":
        print("Metadata:", dist.version, dist._path)
PY

Run this inside the Function App environment, because executing it on the pipeline agent examines the agent’s Python installation instead.

Clean recovery

Deleting the complete .python_packages directory and immediately deploying a clean artifact is preferable to deleting selected .dist-info directories. It avoids leaving a mixture of package code, metadata, compiled extensions, and dependency files from different builds.

Stop the Function App or otherwise prevent requests during cleanup.
Delete /home/site/wwwroot/.python_packages.
Deploy the complete clean ZIP containing the rebuilt .python_packages/lib/site-packages.
Restart the app and run the diagnostic above.
Confirm that the module path is under the expected deployment and that only one aiohttp distribution is listed.

Risk: deleting .python_packages makes third-party imports unavailable until deployment completes. A deployment slot is safer where the hosting plan supports one.

For a local build, recreate the folder rather than installing over an existing target:

rm -rf .python_packages
python -m pip install \
  --target="./.python_packages/lib/site-packages" \
  --requirement requirements.txt

Azure Functions requires locally built dependencies in that directory, and the build environment should match the Linux production environment and Python version.^5^

ZIP deployment deletes or updates files tracked as part of an earlier deployment but can retain other files and directories. That behavior can explain why files created outside the tracked deployment set survive.^6^

Preventing recurrence

Prefer immutable Run From Package where your hosting plan supports it. It mounts the ZIP as read-only wwwroot, so the running tree exactly reflects the package instead of accumulating extracted files.^6^

With AzureFunctionApp@2, explicitly select it rather than relying on auto-detection:

- task: AzureFunctionApp@2
  inputs:
    azureSubscription: 'service-connection'
    appType: 'functionAppLinux'
    appName: 'function-app-name'
    package: '$(Pipeline.Workspace)/drop/function.zip'
    deploymentMethod: 'runFromPackage'

The task supports runFromPackage, which mounts the package instead of extracting it.^7^

Plan-specific constraints matter:

Flex Consumption: already runs from a package; do not set WEBSITE_RUN_FROM_PACKAGE.
Premium or Dedicated: set WEBSITE_RUN_FROM_PACKAGE=1.
Linux Consumption: 1 is unsupported; locally built packages require an external package URL. The Azure DevOps task also states that its deploymentMethod selection is unsupported for Linux Consumption.
Do not combine Run From Package with remote build; remote build instead requires its documented build settings.^6^

References