[Epic] Rollout a Kiota.Bundle package for all languages

[sebastienlevert]

Is your feature request related to a problem? Please describe the problem.

To support the new client generation, we need a new Kiota Core package. That needs to happen for every language.

Client library/SDK language

None

Describe the solution you'd like

We need a package that references all the Kiota packages so we can rely on a single package instead of all the packages + serialization. We also need a derived request adapter to auto-register the serialization pieces.

Additional context

No response

[baywet]

Is core a name we're happy with? Defaults and rollup are good alternatives.

We should take that opportunity to move the dotnet repository to being a monorepo and align the version numbers like we've done for java and it simplifies community contributions, issues management, publishing and more.

[darrelmiller]

If this is just a meta package, then core isn't the right name in my opinion. I'm not a fan of Rollup. Some alternatives:

Kiota.Bundle
Kiota.BaseLine
Kiota.Standard
Kiota.Starter

[baywet]

especially since we already have graph core packages on the other side, I don't want to get into "which core are you talking about?" discussions all the time...

[sebastienlevert]

Kiota.Bundle it is!

[andrueastman]

From an all-language perspective we will ideally need to do the following (in order)

1. Ensure the libraries to a mono repo structure. (This has already been done for TS,Java).

• Dotnet tracked via Group kiota dotnet repositories kiota-dotnet#238
• Go tracked via Group Golang Kiota repositories kiota-abstractions-go#170
• Python tracked via Group python Kiota repositories kiota-python#302
• PHP tracked via Group Kiota PHP repositories kiota-abstractions-php#156
• Ruby tracked via Group Ruby Kiota repositories kiota-abstractions-ruby#43

2. Add a new package/project for the Kiota.Bundle that pulls/depends in the abstractions libraries. (We can probably start this for TS/java as they meet step 1).

3. Expose a derived request adapter to auto-register the serialization pieces.

Open Questions.

• Naming for the derived request adapter?

@baywet Anything you think I may have missed here?

(I can probably add issues for TS/Java step 2 if we think that some of the languages can be done before others.)

[baywet]

Please create the issues for the bundle packages for the languages that are already on a mono-repo.

[andrueastman]

Created issues for bundle packages for languages that meet step 1 criteria (already have mono-repo or won't have one (Go)).

• Dotnet - [Dotnet] Rollout a Kiota.Bundle package kiota-dotnet#290
• Go - [Go] Rollout a Kiota.Bundle package kiota-abstractions-go#172
• TS - [TS] Rollout a Kiota.Bundle package kiota-typescript#1260
• Java - [Java] Rollout a Kiota.Bundle package kiota-java#1420

Other languages will have step 2 issues created once they complete(or invalidate) step 1.

(Updated to include dotnet)

[KennethHoff]

What about simply calling it Kiota (without a suffix)

[sebastienlevert]

I don't have just having Kiota without a suffix... In this case it would be Microsoft.Kiota to be specific. Does that clash with any other of our packages @baywet ?

[baywet]

In the case of dotnet, it'll have to be something along the lines of Microsoft.Kiota.Bundle as it must be under Microsoft (or Azure, or a few other options) from a branding perspective. And our team only has permissions on the Microsoft.Kiota prefix

[sebastienlevert]

We can't release at the prefix level?

[baywet]

Meaning just Microsoft.Kiota?

[andrueastman]

We can't release at the prefix level?

I believe we can. We have an example at https://www.nuget.org/packages/Microsoft.Graph

[baywet]

The only thing I'm worried about with this package name is it will introduce confusion with a generator itself. The current name for the generator .net tool is Microsoft.openapi.kiota. if we introduce the bundle package under microsoft.kiota, this will most likely lead to people trying to install that realize it's not the generation tool having to find the proper name of the generation tool and be mad at us for that reason.

[sebastienlevert]

Good point. Could we think about a v2 of the Generator that could become Microsoft.Kiota.Generator?

[baywet]

Sure, we could rename things. We should be careful about including generator in the package name though in case kiota evolves to do more than just generation. (hidi features, etc...)

[andrueastman]

As an update for this epic. This now rolled out for

• Dotnet - [Dotnet] Rollout a Kiota.Bundle package kiota-dotnet#290
• Go - [Go] Rollout a Kiota.Bundle package kiota-abstractions-go#172
• TS - [TS] Rollout a Kiota.Bundle package kiota-typescript#1260
• Java - [Java] Rollout a Kiota.Bundle package kiota-java#1420

We still need to close

• Python tracked via Group python Kiota repositories kiota-python#302
• PHP tracked via Group Kiota PHP repositories kiota-abstractions-php#156
• Ruby tracked via Group Ruby Kiota repositories kiota-abstractions-ruby#43

for this to be resolved for PHP, Ruby and Python

[sebastienlevert]

@andrueastman have we updated the required dependencies when we do kiota info --l typescript for instance?

[andrueastman]

@andrueastman have we updated the required dependencies when we do kiota info --l typescript for instance?

Thanks for catching that. We'll need to update the info command on the generator this.

#5317 will track this for the 4 langauges and the rest will have it as part of the bundle work item.