Add support for running python projects

[wmeints]

This PR introduces support for running Python projects as part of an Aspire solution. I took the NodeJS extension as inspiration but had to add a couple of extra pieces of logic since Python is a lot less standardized when it comes to how projects are structured.

Initially I created this project: https://github.com/wmeints/aspire-python but I feel that this PR is a much more useful way to add support for Python. I think it's a great resolution for #2760.

Assumptions made by the extension

• Your python project has a virtual environment located under .venv. Although you can change that.
• You have a Dockerfile for publishing the project to test/acceptance/production environments.

[mitchdenny]

@davidfowl I've been thinking about things like Node.js (and now Python). I'm wondering if whether to make things easier for people we should create a boilerplate Dockerfile if one doesn't already exist. The idea being that it gives people a starting point.

So if someone does AddPython...) and points at a particular directory we'll drop down a Dockerfile and .dockerignore file if one doesn't already exist. Then the can tweak it from there customizing the base image etc.

[davidfowl]

I don't think we should be writing files to disk using these APIs, but I like the idea that they would publish as a docker file by default. The publish operation would throw because it couldn't find one. That would instruct the user to add one for their language.

[wmeints]

I can see I broke the build because I forgot to update the playground apphost. I will do that tomorrow morning (GMT+1)

[mitchdenny]

@wmeints this is 95% of the way there - if we can just get the XML doc issues resolved I think we can merge this in!

[wmeints]

@mitchdenny I've had a few crazy weeks but I haven't forgotten about things! I'm going to take a look at the feedback to address issues. Thanks for reviewing :-)

[mitchdenny]

~~@davidfowl @wmeints so I've been thinking about what AddPythonProject does around defaulting to using PublishAsDockerfile. I think that for the initial merge we should leave it to emit an executable.v0 resource and leave it up to developers to call PublishAsDockerfile if they want to.~~

~~My reasoning is that I want to add an extension method to IResourceBuilder<ExecutableResource> for WithDockerfile as the replacement to PublishAsDockerfile.~~

~~I think this will lead to less confusion and greater consistency.~~

I'm second guessing myself here. It might be better for PublishAsDockerfile to take a callback which provides a IResourceBuilder<ContainerResource> which replaces to resource writer (like we do with surrogates). Given this leaving this emitting a dockerfile.v0 for now is the right thing and we would "upgrade" things behind the scenes when we get that mechanic in.

... it would also allow for the PublishAsDockerfile overload to be more resource type specific allowing for sensible default containers to be selected (which could then be overridden by WithDockerfile).

[mitchdenny]

@wmeints looks like we are both working on the branch. I switched you project generation code to use real python and actually setup a virtual environment. We need this so we can actually spin up the project in CI to verify things. @radical hopefully we have Python in the environment ;)

[wmeints]

@mitchdenny, I noticed that you were changing files. I'm going to watch things unfold for a bit. I love how this works on GitHub. I never expected to learn this much about testing a product like Aspire :)

[mitchdenny]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

@radical I think we need to kick the tests in Aspire.Hosting.Tests that were recently enabled for CI back to local only until we can fix the issue of the port conflicts.

[mitchdenny]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

/azp run

[mitchdenny]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[mitchdenny]

@wmeints thanks so much for your contribution to .NET Aspire. We'll be shipping your work in .NET Aspire 8.1!

[dotnet-bot]

:bangbang: Found issues :bangbang:

Project	Coverage Type	Expected	Actual
Aspire.StackExchange.Redis	Branch	42	41.35 :small_red_triangle_down:

Full code coverage report: https://dev.azure.com/dnceng-public/public/_build/results?buildId=720670&view=codecoverage-tab

[wmeints]

Excited to see this appear in 8.1! And thanks again for all the reviews and patience. I learned a lot from this experience. I'm coming back for more 😄

[mitchdenny]

@wmeints I'm writing up the blog post for .NET Aspire 8.1 are you happy for me to link to your GitHub profile for this contribution?

[wmeints]

@mitchdenny Feel free to link my profile in the blogpost :-)