Feature request: dynamic configuration management

[brucechou1983]

Is your feature request related to a problem? Please describe.

Currently, chainlit uses a single config.toml file to manage settings across all ChatProfiles. This creates limitations in providing customized user experiences for different workflows. Specific pain points include:

• All ChatProfiles must share the same UI configuration, regardless of their specific requirements
• Cannot disable/enable features based on the selected profile's capabilities (e.g., image upload for non-vision models)
• No way to dynamically adjust settings when switching between profiles

Describe the solution you'd like

Programmatic configuration settings. Something like

@cl.on_profile_switch
async def handle_profile_switch(profile: ChatProfile):
    # Update configuration for specific profile
    await profile.update_config({
        "sector": {
            "key1": value1,
            "key2": value2
        }
    })

Describe alternatives you've considered
Separate Config Files: Create individual config files for each profile.

• Pros: Simple to implement, clear separation.
• Cons: Duplication of common settings, harder to maintain, no runtime control.

Additional context
I found this issue when building chainlit langgraph integration for creating agentic chatbot.

[dokterbob]

Great point!

Having dynamic configuration management would greatly help with testing as well.

To move forward, I would suggest splitting this issue though:

1. Ensuring that he configuration object is dynamic (e.g. all logic relying on it is stateless).
2. Allow overriding of app init, including loading configuration explicitly -- allowing programmatic initialisation of the configuration.
3. Allowing updating of the configuration from within chat profiles.

If you (or others!) would like to help us move forward, feel free to create separate issues for all of these, linking them to each other (e.g. 2 and 3 both rely on 1) and here, perhaps making a go at spec'ing them. Once these issues are created, we can close this one.

All of this should have at least ~80% unittest coverage and will definitely be required to increase the level of production-readiness of chainlit.

[dokterbob]

@dosu Perhaps you could help us make a start scoping those issues based on our issue/feature template?

[dosubot]

To address the feature request for dynamic configuration management in Chainlit, you can consider the following steps to scope the issues based on the provided suggestions:

1. Dynamic Configuration Object:

   • Objective: Ensure that the configuration object is dynamic and stateless, allowing for changes without affecting the overall application state.
   • Tasks:
     • Refactor the current configuration management to support dynamic updates.
     • Implement mechanisms to ensure that changes to the configuration do not affect other parts of the application unless explicitly intended.

2. Programmatic Initialization of Configuration:

   • Objective: Allow the application to load configurations programmatically during initialization.
   • Tasks:
     • Modify the application initialization process to accept configuration parameters programmatically.
     • Provide hooks or callbacks that can be used to set or modify configurations at startup.

3. Updating Configuration from Chat Profiles:

   • Objective: Enable chat profiles to update their configurations dynamically based on user interactions or profile switches.
   • Tasks:
     • Implement a method within the ChatProfile class to update configurations dynamically.
     • Ensure that these updates are isolated to the specific profile and do not affect other profiles unless intended.

Each of these tasks should be documented as separate issues, with clear dependencies noted (e.g., tasks 2 and 3 depend on the completion of task 1). This structured approach will help in managing the development process and ensure that the feature is implemented efficiently. Additionally, ensure that each task includes unit tests to maintain high code quality and production readiness.

To continue talking to Dosu, mention @dosu.

[brucechou1983]

@dokterbob I will find time to review the current implementation details, provide a reasonable implementation plan, and create sub-issue tickets.