[Python templates] Error on `deploy` after running the `api` server locally

[Victor Vazquez]

Repro:

• azd init -t todo-python-mongo
• azd provision
• azd deploy
• VSCode-> Run Task -> Start API (wait until the api is lauched)
• azd deploy:

Root Cause:
When the api is launched locally, a new folder is created inside the /api folder called api_env. This folder contains a virtual python environment where the application dependencies are installed and where the application is launched from.
Inside this folder, there are some folders which are symLinks to python binaries, like lib64:

When azd deploy runs, a zip file is created including all the content from /api folder, and the create zip implementation from azd does not support symLinks (it doesn't see it as a folder, but as a file, and failed to zip it).

As a workaround, before running azd deploy, we can delete the api_env.

Fix proposals:

1. Make azd to support excluding known folders while doing deploy. The python implementation, for example, should tell azd to ignore the api_env folder when doing deploy. With this approach, we could also skip adding the __pycache__ folders to the zip (those folders are created when running the app locally as well).
2. Use a temporal folder when running the app locally. For example /temp/azdlocalrun/api_env.
3. Use azure.yaml or an extra file (like app.deploy.ignore) to define files/folder which should not be zipped and deployed to Azure. This strategy would allow customers to have control over the deployment files without depending on azd
4. Combine option 1 and 3, where azd would have a hardcoded list of ignore paths and users can also extend the list with configuration files.

[Rajesh Kamal]

@vhvb1989 was this working earlier? is this a regression due to any recent changes?

@v-xuto did you run into this issue?

[Tong Xu (MSFT)]

@rajeshkamal5050 When we were doing manul test according to AzdManualTestPlan.docx, we did not encounter this issue. Because the test scenarios are different. We did not execute azd deploy after VSCode-> Run Task -> Start API.

Our test scenario for executing azd deploy is as follows:

1. azd init -t todo-python-mongo
2. azd provision
3. azd deploy
4. Change “complete” to “completed” in UI
5. azd deploy

Besides, we ran the test and were able to reproduce this issue in linux VM. But, the issue was not reproduced in Windows.

• Azd version: 0.4.0-beta.1 (commit 2bf7a52)
• Branch : main

[Victor Vazquez]

@vhvb1989 was this working earlier? is this a regression due to any recent changes?

@v-xuto did you run into this issue?

Not a regression. This issue has been there since early versions (as it is within the zip strategy).
It was just not yet discovered. (This means no one has been running the api server locally for python and later calling deploy after some changes to the code).

[Wei Lim]

@vhvb1989 We already hardcode the list of ignored files/directories, such as for npm or python:

azure-dev/cli/azd/pkg/project/framework_service_python.go

Lines 44 to 48 in 2a8a4ad

 if err := copy.Copy( 
 	publishSource, 
 	publishRoot, 
 	skipPatterns( 
 		filepath.Join(publishSource, "__pycache__"), filepath.Join(publishSource, ".azure"))); err != nil { 

azure-dev/cli/azd/pkg/project/framework_service_npm.go

Lines 61 to 65 in 2a8a4ad

 if err := copy.Copy( 
 	publishSource, 
 	publishRoot, 
 	skipPatterns( 
 		filepath.Join(publishSource, "node_modules"), filepath.Join(publishSource, ".azure"))); err != nil { 

If it never makes sense to package api_env for python, then it makes sense to skip it similarly by hardcoding.

I think we should also address the following:

1. Immediate: Handling symlink directories -- this should result in a copy failure
2. Long-term: having .azdignore or ignore_pattern inside azure.yaml would be great thing.

[Rajesh Kamal]

Similar bug on functions #1039

[Pamela Fox]

I would also like for azure.yaml to have an ignore/exclude mechanism. I was the one that reported that funcignore isn't being obeyed for functions, but now I'm in an App Service situation where I'm in need of a similar mechanism. I can't re-structure the code in this situation since I'm trying to add azd support to an existing project structure. Deploying is taking a very long time, since it's unnecessarily deploying the node_modules and venv directory.

[Wei Lim]

@vhvb1989 I was working on a different part of the codebase and stumbled upon the copy.Copy implementation.

Do you think we can get away with doing hard-copy instead of shallow-copy when handling symlinks for packaging? The library does support it:

[Victor Vazquez]

stumbled

IIRC, shallow copy helps for files that are currently in use/locked. The root cause here is copying files which should not be copied