Multiple entry points for single TypeSpec project

[jpalvarezl]

Clear and concise description of the problem

What is this about

We are currently trying to normalize all language client libraries for Azure OpenAI services to use the same TypeSpec definition found in this repository. This TypeSpec project defines 2 layers, one for pure OpenAI (under the ./.typespec folder) and the Azure elements extending the OpenAI service definitions (under ./.typespec.azure).

Currently, there are several libraries that are defined in the base OpenAI TypeSpec definition. Since this definition is an upstream dependency, we can't really split the definition itself. What would be very useful to us, is to be able to define multiple entry points for all our libraries generated from this monolithic TypeSpec spec (this spec is generated and parts are handcrafted from the OpenAI and the Azure OpenAI rest API swagger docs).

Proposal

For us, it would be ideal to be able to define multiple main.tsp and clien.tsp files with their respective tsp-config.yaml files in subfolders of the repository. For example, being able to define these files under .typespec/realtime would allow us to ship a separate client library from that spec of what, from the service side, is a beta feature.

Our idea for consuming the new entry point for the spec in a separate hypothetical library, would be to have an additional key in the tsp-location.yaml file from the new client library repository folder, specifying which main.tsp or client.tsp file the code generation tree should start branching from. Currently, using tsp-client sync && tsp-client generate will run code generation from either the main.tsp or client.tsp file located at the root of the directory specified in the tsp-location.yaml file.

Alternatives

We could try leveraging namespaces to define the client library boundaries. This is not without the risk of running into the situation in the future that there are shared elements across different libraries defined in the same spec.

cc: @srnagar , @trrwilson

Checklist

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[timotheeguerin]

is this more a question for the azure spec repo organization? You can have as many entrypoint as you'd want for TypeSpec.
tsp-location.yaml is also a `tsp-client/azure spec repo specific file)

[jpalvarezl]

I am happy to re-direct the question if this is not the right place. I just wanted to figure out how with the current tooling (if possible) we could have many main.tsp and client.tsp pairs in a single monolithic TSP project and how we can consume those specific entry points in separate client libraries.

In the link I provided in the description, we use a monolithic TSP definition, from which we would want to derive separate libraries. Would it be simply a matter of changing the tsp-location.yaml file's directory: .typespec/realtime , for example?

The difficulty I have found is that there needs to be a namespace annotated with @service somewhere, and having several would result in an error, as far as I could tell. Our idea would be to be able to pick operations and models from the monolithic definition and compose clients just by doing that. The service/server remains the same across client libraries.

[timotheeguerin]

I think so, though I do not know much about the tsp-client configuration and what is possible there(@catalinaperalta do you know). In the azure spec repo some services are organized like that if that helps knowing what is possible

specifciation/org/
  service1/
     main.tsp
     client.tsp
  service2/
     main.tsp
     client.tsp
  common/
    main.tsp

[catalinaperalta]

It seems to me like you need separate tspconfig.yaml files for each sub project you want to generate. So with tsp-client you could call the command with the specific tspconfig.yaml for the service section and likewise that should create an appropriate tsp-location.yaml for you.

So using Tim's example above, I think you could have something like:

specifciation/org/
  service1/
     main.tsp
     client.tsp
     tspconfig.yaml
  service2/
     main.tsp
     client.tsp
     tspconfig.yaml
  common/
    main.tsp

So if you want to generate service1 you'll use the tspconfig.yaml under it and your tsp-location directory should be: specification/org/service1.