Consider renaming component packages to Aspire.Components.*

[davidfowl]

Today aspire components are named Aspire.{existing library name} and the hosting packages are Aspire.Hosting.*. This makes it difficult to talk about components because there's no consistent prefix (e.g. Aspire.Components.*). We should consider renaming these libraries so that the prefix is clear in the name of the package. This will make them easier to document and talk about.

[mitchdenny]

Before GA?

[davidfowl]

If there’s time and we agree the yes

[mitchdenny]

/cc @eerhardt @danmoseley @joperezr @IEvangelist

[mitchdenny]

Conceptually I can see the benefit. But it's a big change to take this late.

[davidfowl]

Agree, I think we either do it or close it.

[danmoseley]

If the change compiles, what could still break? Not rhetorical question... looking for brainstorming.

[danmoseley]

Samples, docs, apps built on previews,... any tooling issue? Nuget package renames?

[davidfowl]

Not sure what would break in the tooling. We haven't built higher level experiences on top of these packages as yet AFAIK.

cc @vijayrkn @BillHiebert @timheuer @bradygaster

[mitchdenny]

Obviously any existing code would need to be updated. If folks don't know about the change then they would continue referencing the old version of the package which could raise support issues.

[mitchdenny]

We'd obviously want to delist all the old versions of the package.

[mitchdenny]

I've been thinking about this some more. I'm not sure what value it provides. The namespaces are already disambiguated due to Aspire.Hosting.* and really the Aspire.* prefix for Aspire-component libraries is as a minimal as possible prefix.

When we start seeing third party contributions we probably aren't going to allows folks to use the Aspire.* prefix for something that doesn't come out of our repository - so the namespaces are already going to be a bit fragmented.

[timheuer]

Sorry to maybe be a naysayer here but I don’t think this adds any value (or at present takes any away). This doesn’t feel worth any disruption TBH. Id rather us find more obvious ways in experiences to make any confusion more intuitive.

[davidfowl]

right now it’s very hard to talk about component packages because the naming pattern relies on the underlying client library. We also can’t say that they are called Aspire. because that includes Aspire.Hosting.. The only way to talk about components as a group of packages is to say they are tagged with component which nothing in the toolchain will tell you.

I wouldn’t die on this hill but I’ve been explaining the thsthat apphost packages are Aspire.Hosting.* and component packages are Asprie.{figure that shit out}

[davidfowl]

When we start seeing third party contributions we probably aren't going to allows folks to use the Aspire.* prefix for something that doesn't come out of our repository - so the namespaces are already going to be a bit fragmented.

Will these show up as aspire components?

[mitchdenny]

Will these show up as aspire components?

That is a good question. Is the policy around when we decide to promote a package through that experience been nailed down? Do we care about the provenance?

Even so ... my point still stands. We probably are not going to allow anyone but us to publish a package under Aspire.* - certainly not out of some random repo.

[davidfowl]

Even so ... my point still stands. We probably are not going to allow anyone but us to publish a package under Aspire.* - certainly not out of some random repo.

Those aren't aspire components and aren't relevant to this discussion right?

[danmoseley]

Those aren't aspire components and aren't relevant to this discussion right?

We expect folks will want to create Aspire components out of other repos and offer them for use. We may well ask that those use a different package and namespace prefix (for one thing, we own that prefix in NuGet, and would have to explicitly release sub-namespaces .. all this begs question of the picker experience). @mitchdenny is suggesting we probably would ask they use a different namespace. In which case many components wouldn't be inside the hypothetical Aspire.Components namespace prefix anyway.

Perhaps I'm missing something?

[davidfowl]

Yea, I was pretty sure the point of using a prefix was to use the prefix 😄. When 3rd party package show up, they will show up on nuget.org, but they don't show up as aspire components, right?

[danmoseley]

That depends on several decisions that haven't been made, including to what extent we think we are curating and how that should be evident to the user.

[danmoseley]

Either way, I don't think tooling will need any particular namespace any more than it does now. So this is just a tidiness proposal. If we create a component ServiceHosting (making up random words here) and then later want to add an Aspire feature of this sort, there could be a namespace collision as things stand.

[BillHiebert]

As long as these are still tagged in Nuget with "owner:Aspire tags:hosting" I don't think tooling is affected.

[eerhardt]

If the change compiles, what could still break?

Templates.

We also can’t say that they are called Aspire. because that includes Aspire.Hosting.. The only way to talk about components as a group of packages is to say they are tagged with component

I'm not sure what the problem is with saying "they are tagged with component". Isn't that what tags are for? To make arbitrary groups of packages?

which nothing in the toolchain will tell you.

I don't understand this part. We have this from "Add => .NET Aspire Package"

and on the right side of NuGet package manager it shows the tags. The tags are also shown in nuget.org, and you can query them there as well: https://www.nuget.org/packages?page=2&q=owner%3Aaspire%20tags%3Acomponent

---

I don't think adding another (large-ish) word to the package name adds more value than the complexity it adds. Having to say "Aspire Components" before every package ("Aspire Components StackExchange Redis", "Aspire Components Azure Storage Blobs", "Aspire Components Azure Messaging EventHubs", "Aspire Components Npgsql EntityFrameworkCore PostgreSQL") doesn't add value IMO. It just adds complexity and verbosity.

[IEvangelist]

I don't think that we should change this. While I understand the argument for having a clearer separation of concerns, i.e., Hosting vs. Components, it's going to get really ugly 🤮.

I think that with preview-5 we started seeing things a lot more clearly, now that hosting has an Aspire.Hosting.* pattern. I think that this change alone was enough to solve the symptom of the original concern.

It's now clear that those are hosting concerns now. But if we had Aspire.Components.* we'd end up packages like this, and since the term is so overloaded—it's not a helpful chane:

• Aspire.Components.Npgsql.EntityFrameworkCore.PostgreSQL
• Aspire.Components.Pomelo.EntityFrameworkCore.MySql

We'd end up in a place where we have laughably long package names 🤣.

[davidfowl]

What happens when we have dashboard extensibility via Aspire.Dashboard.* packages. What happens when a library we want to write a component for starts with Hosting? These are the reasons for the prefix

[IEvangelist]

What happens when we have dashboard extensibility via Aspire.Dashboard.* packages.

That's specific to the dashboard, not related to hosting and certainly not considered a component. So, unaffected by not having Aspire.Components.*.

What happens when a library we want to write a component for starts with Hosting?

Sure, valid concern, but with your approach you'd end up with Aspire.Components.Hosting.Some.Unrealistic.Package 😏. Which is arguably worse... Also, after a quick look on NuGet, I only found one package thus far that starts with Hosting, and it's unlikely it would be considered a component. 🤷🏼‍♂️

[En3Tho]

I actually think it can add clarity.

In the ide an extra word is not a problem - usually all those things are imported automatically anyway.

But when searching for comppnent nuget packages you could use something like "aspire.c" and get much more relevant results than just everything under "aspire".

This also clearly separates parts of the framework where things under Aspire. are core parts and Aspire.Components. are basically "plug-ins"

[IEvangelist]

I think one of my largest concerns with Aspire.Components.* is that I'm personally just hung up on components. It's just too overloaded and we'd be doing ourselves a disservice by naming it that.

Also, thanks for nothing Copilot:

Considering the context that the term "components" might be too generic and overloaded, here are some alternative naming suggestions for your Aspire library packages:

• Aspire.Modules
• Aspire.Elements
• Aspire.Parts
• Aspire.Units
• Aspire.Sections
• Aspire.Fragments
• Aspire.Blocks
• Aspire.Pieces
• Aspire.Constituents

These alternatives aim to convey the idea of individual parts of a whole, which can be assembled or used to build more complex structures, similar to components but with a distinct terminology. Make sure to check for any existing usage of these terms within your organization to avoid conflicts. Happy coding!

If you're thinking that all of these sounds redundant, you're right, so does Aspire.Components.* 🤓 .

[timheuer]

I, for one, will be definitely getting my Aspire.Constituents in line. It's very important in an election year.

[davidfowl]

We agreed not to rename the packages, but spend time looking at if we can improve the documentation in this space. Maybe we no longer refer to these as components since that term is so generic or maybe we leave it alone and have people deal with the chaos we have created. Deadline for this decision is Friday.

[IEvangelist]

I, for one, will be definitely getting my Aspire.Constituents in line. It's very important in an election year.

Yeah, I saw that one - LOL

[bradygaster]

I concur with @timheuer's commentary on the value this would add.

[eerhardt]

Closing as we are locking down for shipping the 8.0.0 GA release and we aren't convinced this is the correct long term decision (given the above feedback/discussion). We will consider ways we can make the documentation more clear on what these libraries are and how to tell the difference between the Aspire.Hosting.* libraries and the Aspire.* libraries.