-
Notifications
You must be signed in to change notification settings - Fork 75
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
support modular models in multiclient #2556
support modular models in multiclient #2556
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good candidate for smoke test as it has serialize utils for multi sub client clients in Modular. @joheredi Let me know if you have any concerns.
} | ||
|
||
/** serialize function for ChatRequestMessageUnion */ | ||
export function serializeChatRequestMessageUnion( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joheredi, Currently getAllModels are not bounded by the client decorators, so even if we have generate the models/models.ts in several different subclient's folder, they are actually redundant, and serializeUtils are bound with the models, in this fix, they are also redundant https://github.com/Azure/autorest.typescript/pull/2556/files#diff-182a11512248c84c2b807878be3b3743021b2565342194c7b77d269fefdcba59
I vaguely remember we have some discussion about this, when we support multiclient in modular, the conclusion is that we should make sure to have subpath export for both api and models for each subclient.
packages/typespec-test/test/ai_modelClient/generated/typespec-ts/package.json
Outdated
Show resolved
Hide resolved
...est/test/NetworkAnalytics.Management/generated/typespec-ts/src/classic/dataProducts/index.ts
Show resolved
Hide resolved
Summary of changes in this PR:
|
], | ||
"exclude": [], | ||
"compilerOptions": { | ||
"outDir": "../.tshy-build/browser" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should remove files under .tshy
?
@@ -2,7 +2,7 @@ | |||
// Licensed under the MIT license. | |||
|
|||
/** The response of entire anomaly detection. */ | |||
export interface UnivariateUnivariateEntireDetectionResultOutput { | |||
export interface UnivariateEntireDetectionResultOutput { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems we have name collisions here(that's why we have prefix with namespace before), but i didn't notice any name suffix with _N, could you share the link with me?
@@ -9,31 +9,31 @@ import { OperationOptions } from '@azure-rest/core-client'; | |||
import { Pipeline } from '@azure/core-rest-pipeline'; | |||
|
|||
// @public (undocumented) | |||
export interface A { | |||
export interface A0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha, we start with _0? i was wondering if we just keep A as A for the first one?
@@ -465,6 +459,7 @@ export interface ChatRequestUserMessage extends ChatRequestMessage { | |||
// @public | |||
export interface ChatResponseMessage { | |||
content: string | null; | |||
// Warning: (ae-forgotten-export) The symbol "AzureChatExtensionsMessageContext" needs to be exported by the entry point index.d.ts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could fix this warning?
@@ -129,12 +129,6 @@ export interface AzureChatExtensionDataSourceResponseCitation { | |||
url?: string; | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this expected? it seems relevant to this change: #2556 (comment).
nameSet.set(model.name, [ | ||
...nameSet.get(model.name)!, | ||
model.__raw! as Model | ||
]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: could we directly add items into original array? so that we don't need to build a new array every time.
@@ -19,6 +19,7 @@ import { | |||
serializeRequestValue | |||
} from "./helpers/operationHelpers.js"; | |||
import { ModularCodeModel, Type } from "./modularCodeModel.js"; | |||
import path from "path/posix"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why path/posix
not path
directly? it seems posix would stick to posix style, not sure if we have issue in non-unix environement https://nodejs.org/api/path.html#windows-vs-posix?
import { KnownMediaType } from "./mediaTypes.js"; | ||
|
||
export interface SdkContext extends TCGCSdkContext { | ||
rlcOptions?: RLCOptions; | ||
generationPathDetail?: GenerationDirDetail; | ||
hasApiVersionInClient?: boolean; | ||
nameModelMap?: Map<string, Model[]>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you know we have a ContextManager, i was wondering if saving this information into there would be more proper?
@@ -61,7 +61,7 @@ function extractRLCOptions( | |||
dpgContext, | |||
emitterOptions | |||
); | |||
const enableModelNamespace = getEnableModelNamespace( | |||
const autoResolveModelConflict = getEnableModelNamespace( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we change the getter function name here also?
@@ -64,15 +67,37 @@ export function getOperationNamespaceInterfaceName( | |||
|
|||
export function detectModelConflicts(dpgContext: SdkContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we leverage this in RLC also? Is it problematic when we plan to get rid of tcgc dependency in RLC?
close it as most of the change has been taken by binder pr. |
fixes #2554
fixes #2611
see design doc.
Discussion Conclusion:
Model Generation:
Name Collision Detection:
Handling Name Collisions (Process):
Warning and Reporting:
Action Items