Skip to content
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

Add Manifest Provider #108

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Lensual
Copy link
Contributor

@Lensual Lensual commented Jul 16, 2024

form #78


Add a manifest.json provider class. Its read manifest.json to memory only, no change to origin file.

  • LoadManifest: read manifest from dir.
  • injectEnvVar: inject Environment Variable to json content.
  • GetManifestJson: give a vendor, return manifestJson.

@Lensual
Copy link
Contributor Author

Lensual commented Jul 16, 2024

manifest.json must changed to manifest.azure.json

Please confirm if it is feasible.

@Lensual Lensual marked this pull request as ready for review July 16, 2024 19:22
@sunshinexcode
Copy link
Collaborator

@Lensual
这块 manifest 后面还需要内部再讨论, 多个编排怎么存放, 是一个 manifest.json 内部包含多个 graph, 还是以现在多编排文件形式, 如果是多编排文件, 还涉及到如何规范定义命名(命名规则).

@Lensual Lensual marked this pull request as draft July 17, 2024 17:03
@plutoless
Copy link
Contributor

thanks for the PR. i think the concept of ManifestProvider is brilliant.
as our extensions keep growing, i guess we will need more flexible ways to adjust single model based on a specific use-case template, instead of creating manifest for every possible combination.

below is my proposal, open for discussion,

  1. to provide a usecase manifest template. the template will basically follow the default ASTRA manifest example, while make model extensions as a place holder (e.g. <llm_extension>, <tts_extension>)
  2. to provide a vendor config json to manage extension property settings, {llm: {openai: {...openai extension configs}}}
  3. In manifest provider, based on user request, choose the use case template he want to use, and vendor he want to use, and merge them to get a dynamic generated manifest for agent to use

Before we are reading environment variables and request payload to overwrite property values of manifest json, now we should write to vendor config json (e.g. api keys) or generated manifest file (e.g. voice types)

Let me know what you think.

@plutoless
Copy link
Contributor

plutoless commented Jul 30, 2024

we have some discussion today and decided to reduce manifest template - there are simply too many of them.
we are planning to separate the graph dynamic settings into a different file so that you can define multiple and choose one of them. pls ignore my last comments and we will provide an updated solution for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants