Meta: Strategy around obsoleting/moving infrequently used extensions out of tree?

[mitchdenny]

This community contributed PR is adding Python support (awesome) but it is also looking at adding extensions/resources for popular Python frameworks such as Django and Flask.

We need to figure out what our policy is on introducing APIs for application frameworks that may have less durability than the host language/runtime. I'm not suggesting that Django and Flask aren't here to stay, I'm just saying that this situation may arise in the future and it would be good to have some sense of what our approach should be:

Should we:

1. Avoid introducing APIs that we might need to obsolete in the future and encourage them to be published as independent packages.
2. Encourage the contributions but put them in separate packages (e.g. Aspire.Hosting.Python.Django)
3. Co-locate them with their host language/runtime.

[wmeints]

I think adding a little background from my perspective to this discussion is helpful.

I'm creating the PR for Python support. I designed the code in my PR with Django/Flask/FastAPI in mind because they are popular in the Python ecosystem. They also solve a problem that Python has with how you run projects written in the mentioned web frameworks.

My idea is that while basic Python support shows that Aspire goes beyond .NET, it doesn't quite add the value that we need to work effectively with Python in an Aspire environment.

Python has a particular challenge around running applications based on one of the mentioned frameworks. You often need specific command-line arguments to run them. For example, Flask has an entirely different command-line structure than Django. Add to that the instrumentation story for open telemetry, and you've got yourself quite a nasty challenge for developers working with the mentioned frameworks.

I added the specific API interface to address the two challenges: command-line structure and open telemetry instrumentation. The downside of my design direction is apparent: It makes it harder for the team to keep up with changes
in the Python ecosystem.

Option 1 allows developers to move at their own pace. However, discoverability is a challenge here. Components provided by third-party developers are hard to find. That may change in the future, but it does potentially hold back Aspire a little bit in adoption. If there was a way to promote third-party extensions, option 1 could be more attractive.

Option 2 offers a nice hybrid solution. On the one hand, people can grab something "out-of-the-box" and get going. It's highly discoverable. At the same time, if a third-party component or framework is in decline, you can phase out the associated Aspire components. While building my own extension, I did find that I'm locked into Aspire's release cadence.

@mitchdenny I'm not sure what you mean with option 3. Could you elaborate on that option?

[mitchdenny]

Option 3 was basically your PR as it is now.

Appreciate your perspective on this. I think it's pretty compelling. I'm leaning towards option 2 myself but interested in @davidfowl, @eerhardt, and @DamianEdwards perspective here.

[davidfowl]

I think 2 is where I am landing on this. We may end up with a package explosion though. Maybe that's not a problem in practice?

[wmeints]

For the specific of the python frameworks I don't foresee any issues soon. What's the impact of deprecating an extension?

[danmoseley]

@eerhardt

[mitchdenny]

@wmeints primarily the issue with deprecating an extension is that it creates friction for those projects (that use it) to adopt newer versions of .NET Aspire. In practice though that friction would exist whether it was in tree or out of tree.

[eerhardt]

My opinion about the extensibility model of Aspire is that we are going to have to be fine with obsoleting (and eventually removing) things that are end-of-life / unmaintained / unused. The cloud landscape moves too fast. We aren't dealing at the same level as dotnet/runtime or even dotnet/aspnetcore. APIs for reading files, sockets, HTTP, collections, etc. don't come and go as fast as higher level technologies.

Whether these packages are "in tree" or "out of tree" doesn't really affect this. If an Aspire API is made for technology X, and technology X is canceled, the Aspire API for technology X needs to be canceled as well.

[davidfowl]

It's not just about deleting things, but updating as well. Coupling things that don't version together even though they are from the same ecosystem might be a problem.

[mitchdenny]

OK so just to round this out and so we can give some guidance back to @wmeints ... shall we go with Aspire.Hosting.Python.Django as a way of isolating app frameworks into a separate package? That assumes that having an app framework specific APIs actually adds value (that may not always be the case).