We Keep Coding

Python Running Coverage report on host when data collected inside container

I am using Coverage.py
My use case is as follows:
My test is devised of several different processes. Each inside its own container. I would like to get a single coverage report on the entire test
The python packages that I would like to track are usually installed in the base python of the containers, and in one container it is in virtual environment (instead of base python)
I output a different .coverage file for each and would like to
Combine them (they do share some libraries that I would like to get coverage on)
Report to html
The issue is that the paths are local to the container which captured the coverage.
I would like to run combine and report on the host.
I know that for combine I can use [paths] to alias different paths that are the same (haven't worked with it yet since I am trying to run a single process at first).
I am not sure how to get the correct paths in the report.
When I run report I get an error of "no source for code" which makes sense but I can't find a way to run the report on the host even though all of the code exists on the host.

Central Directory Corrupt deploying Python Azure function

I was previously able to deploy an Azure function written in Python using the command func azure functionapp publish <FunctionAppName> from my project directory, building it remotely. It worked until lunchtime yesterday.
I now get the following message.
Creating archive for current directory...
Performing remote build for functions project.
Deleting the old .python_packages directory
Uploading [######################################################################################]
Remote build in progress, please wait...
Fetching changes.
Cleaning up temp folders from previous zip deployments and extracting pushed zip file /tmp/zipdeploy/c5e66350-4b87-4e72-9900-b2a1ae4521a8.zip (0.00 MB) to /tmp/zipdeploy/extracted
Central Directory corrupt.
Remote build failed!
I've tried the following to see if I can resolve it without any success:
Switching my machine off and on.
Deploying an older version of the code in case I've changed anything.
Deploying from the command prompt in visual studio code.
Reinstalling Azure functions core tools.
Deploying from a different machine on a different network (I read that there are sometimes firewall issues with uploading zip files but my IT manager assures me we have no restrictions and these settings have not been changed). In doing so, I had to install Azure functions core tools from scratch as it had never been installed on that machine before.
Creating a completely new clean functionapp and deploying there.
Creating a brand new minimal Python application in a clean directory and deploying this to the new functionapp.
I get the same message in each case.
I'm stuck here. Does anyone have any more information about what the error message might mean is going wrong or any ideas?
Other investigations -
I've tried deploying as a different Azure user (same error).
I've checked for any processes using port 9091 (none were found).
I have also tried to build locally using func azure functionapp publish IncidentProcessing4 --build local
I got some different error messages
Performing local build for functions project.
Directory .python_packages already in sync with requirements.txt. Skipping restoring dependencies...
Uploading package...
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
Retry: 1 of 3
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
Retry: 2 of 3
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
Retry: 3 of 3
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
I noticed that in my \users\name\appdata\local\temp directory 2 files had been created by the build, called temp374D.tmp and tmp374E.tmp. The first of these was 0KB in size and the 2nd 8KB in size.
My suspicion is something is causing the first file to be created and something on the server is attempting and failing to unzip it.
More additional information - "Deploy to Function App" from Visual Studio code deploys, but when the Azure function runs, I get errors about modules referenced by the function not being loaded. If it's possible to deploy the modules in requirements.txt with the function app that will be a work around.

I think I've fixed it by reverting to an earlier version of Azure Functions Core Tools. It's deploying with 2.7.1575.
I'll experiment to see if I can find out any more but I've got my function deploying now.

This may not apply, given your exhaustive set of things you did trying to diagnose the issue, but I'll throw it out there. I have run into this if my function is running, either in a terminal window (via func host start) or even via the VSCode functions extension.
It would seem like it should be obvious to see if anything's running, but I've seen VSCode leave behind function host processes in a running state. To check, you could check netstat (netstat -a -n | grep 9091) or lsof (lsof -nP -iTCP:9091 | grep LISTEN). The latter gives you the pid that has the port open.

It seems that there was a bug introduced in Azure Functions Core Tools such that if your function directory full path had a space character in it Eg- /home/my functions project/, it would create a zip package with 0 bytes.
See - https://github.com/Azure/azure-functions-core-tools/issues/1867
This will be fixed in the next release. In the meanwhile, anyone experiencing this can mitigate the problem if they switch their function project to be in a path without space characters.
Sorry about that!

I am using core-tools version 3 and the same problem exists there as well. As Ankit mentioned in his answer, the issue occurs when there's a space in the project path.
One solution to this could be to move your project to another path without spaces until the next release fixes the issue but this is not always feasible/desirable. Instead we can create a shortcut (aka junctions on windows systems) to the original folder in a new path without spaces. So here's a batch file snippet which uses junctions for publishing functions to Azure till next release.
:: login and create resources with cli
....
:: enter into a path of choice without spaces (eg. my Windows Temp folder path has no spaces)
pushd %PATH_WITHOUT_SPACES%
:: create a junction to project path here and navigate to it
mklink /J tmpdir %PROJECT_PATH_WITH_SPACES%
pushd tmpdir
:: execute publish as you would normally. It will succeed now!
call func azure functionapp publish %APP_NAME%
:: cleanup and return to old working dir
popd
rmdir tmpdir
popd

Debug python (in Docker) from VS Code

I have a python application with various dependencies that get resolved during docker-compose build command. A docker image is created, and when run it's a simple REST API that I can access via a browser.
I want to send a GET request and then debug the corresponding method in VS Code. However I'm struggling to get this to work. I'm able to get the docker image running from within VS Code (using Remote-Containers: Open Folder in Container option). I can see the API is up and changes in the code are reflected live.
However I'm struggling to get the debugging part to work.
When I start debugging, I'm asked to provide a Debug Configuration and I'm not sure what the right one to pick or how to set one up....

Please see the documentation on debugging on how to create a debug configuration.

What does the Docker tutorial mean by "grab a portable Python runtime as an image"?

I am starting the Docker tutorial with the Python app and would like to know what is the meaning of "Python runtime" in this context:
In the past, if you were to start writing a Python app, your first order of business was to install a Python runtime onto your machine. But, that creates a situation where the environment on your machine has to be just so in order for your app to run as expected; ditto for the server that runs your app.
With Docker, you can just grab a portable Python runtime as an image,
no installation necessary. Then, your build can include the base
Python image right alongside your app code, ensuring that your app,
its dependencies, and the runtime, all travel together.
So I guess what it mean is the "Python runtime" is like the configuration of your local Python.

When it says "Python runtime," it just means the Python interpreter in a binary format and its local configuration of package dependencies. Your interpretation is correct.

Jenkins Build Python Project

I need to set up a Jenkins server to build a python project. But I can't find any good tutorials online to do this, most of what I see uses pip, but our project simply works on
python.exe setup.py build
I've tried running it as a Windows Batch file setting it up through the configure options in Jenkins, where I enter the above line in the box provided, but the build fails.
When I try to run this I get a build error telling me there is no cmd file or program in my project's workspace. But it seems to me that cmd would be a program inherent to Jenkins itself in this case.
What's the best way to go about setting up Jenkins to build a python project using setup.py?

Really i used jenkins to test Java EE project and i don't khnow if it will be the same principle or not ,
so i downloaded the jenkins.war from the website and i deployed it on my jboss server and I reached it via an url on the browser : http://localhost:serverport/jenkins the i created a job and i select the server & jdk & maven & the location of my project in workspace then i make a run to build the project.
I am sorry if you find that my subject is far from your demand but I tried to give you a visibility onto my use.

I relaized I did something stupid and forgot that my coworker had set it up on a UNIX server, so I should have been using the shell instead of Windows Batch. Once I changed that and installed the python plugin, I got it to build fine.