Rollout a Kiota.Bundle package for all languages

sebastienlevert commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Kiota.Bundle it is!

andrueastman commented 2 weeks ago

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

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

[x] Dotnet tracked via https://github.com/microsoft/kiota-abstractions-dotnet/issues/238
[x] Go tracked via https://github.com/microsoft/kiota-abstractions-go/issues/170
[ ] PHP tracked via https://github.com/microsoft/kiota-abstractions-php/issues/156
[ ] Python tracked via https://github.com/microsoft/kiota-abstractions-python/issues/302
[ ] Ruby tracked via https://github.com/microsoft/kiota-abstractions-ruby/issues/43

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).
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 commented 2 weeks ago

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

andrueastman commented 2 weeks ago

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

[ ] Dotnet - https://github.com/microsoft/kiota-dotnet/issues/290
[ ] Go - https://github.com/microsoft/kiota-abstractions-go/issues/172
[ ] TS - https://github.com/microsoft/kiota-typescript/issues/1260
[ ] Java - https://github.com/microsoft/kiota-java/issues/1420

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

(Updated to include dotnet)

KennethHoff commented 2 weeks ago

What about simply calling it Kiota (without a suffix)

sebastienlevert commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

We can't release at the prefix level?

baywet commented 2 weeks ago

Meaning just Microsoft.Kiota?

andrueastman commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

baywet commented 2 weeks ago

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...)

microsoft / kiota