Skip to content

Update openai spec to use access and usage #25856

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Nov 10, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 16 additions & 6 deletions specification/cognitiveservices/OpenAI.Inference/client.tsp
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,25 @@ using Azure.ClientGenerator.Core;

// Azure-specific long-running operations should be treated as implementation details that are wrapped into
// appropriately merged public surface.
@@internal(Azure.OpenAI.beginAzureBatchImageGeneration);
@@internal(Azure.OpenAI.getAzureBatchImageGenerationOperationStatus);
@@access(Azure.OpenAI.beginAzureBatchImageGeneration, Access.internal);
@@access(Azure.OpenAI.getAzureBatchImageGenerationOperationStatus, Access.internal);

// Azure-specific Chat Completions with extensions should be handled by clients as a conditional selection within the
// shared Chat Completions route, with the selection gated by the presence or non-presence of additional child
// configuration options on the request payload options model.
@@internal(Azure.OpenAI.getChatCompletionsWithAzureExtensions);
@@access(Azure.OpenAI.getChatCompletionsWithAzureExtensions, Access.internal);

// Some models from routes with suppressed visibility are still desired for custom public surface.
@@include(Azure.OpenAI.ImageGenerationOptions);
@@include(Azure.OpenAI.ImageLocation);
@@include(Azure.OpenAI.ImageGenerations);
@@access(Azure.OpenAI.ImageGenerationOptions, Access.public);
@@access(Azure.OpenAI.ImageLocation, Access.public);
@@access(Azure.OpenAI.ImageGenerations, Access.public);
@@access(Azure.OpenAI.ImageSize, Access.public);

@@access(Azure.OpenAI.AzureCognitiveSearchIndexFieldMappingOptions, Access.public);
@@usage(Azure.OpenAI.AzureCognitiveSearchIndexFieldMappingOptions, Usage.input);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.NET can generate but failed if including
@@usage(Azure.OpenAI.AzureCognitiveSearchIndexFieldMappingOptions, Usage.input);

@joseharriaga

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, there appears to be two issues in C#:

  1. If I add this line:
    @@usage(Azure.OpenAI.AzureCognitiveSearchChatExtensionConfiguration, Usage.input);
    The code generation fails completely.

  2. If I remove the previous line and add this other line:
    @@usage(Azure.OpenAI.AzureCognitiveSearchIndexFieldMappingOptions, Usage.input);
    The code generation succeeds, but generates a Write serialization method for the AzureCognitiveSearchIndexFieldMappingOptions class. However, this class already has a custom Write method, so the compiler complains about having two different definitions and fails to build.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This comes from you have customized the properties SearchKey as type property AzureKeyCredential. I'm curious why you want to store credential in a model?
  2. Yeah if they are the same you could remove the one in customization class. That is why I introduce this change - to remove the customization code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This model is an input, and the SearchKey property is used to pass the API key that is needed to connect to the target Azure Cognitive Search resource. Since users are already familiar with AzureKeyCredential as way of handling API keys, it made sense to us to make this property be an AzureKeyCredential itself. Let me double check with the .NET architects what they think about this approach.
  2. You're right that since the generated code is identical to the custom code, we can simply remove the custom code and it would work. That being said, would it be more appropriate if the emitter realized that there is already a customization and not emit the generated code unless the customization is removed first? This would prevent the emitter from producing code that the compiler cannot build.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Yeah, that is something could be discussed.
  2. I don't think it would be a good practice. Think about we have an update of the method body someday, then the final composed code would still have the old body in customization, which is not we are expecting.


@@access(Azure.OpenAI.AzureCognitiveSearchQueryType, Access.public);
@@usage(Azure.OpenAI.AzureCognitiveSearchQueryType, Usage.input);

@@access(Azure.OpenAI.AzureCognitiveSearchChatExtensionConfiguration, Access.public);
@@usage(Azure.OpenAI.AzureCognitiveSearchChatExtensionConfiguration, Usage.input);