Addon params

[3ammari]

Description

[Briefly describe the changes made in this pull request.]

This PR introduces the addon_params feature, allowing users to pass additional configuration parameters via the --addon_params argument or the ADDON_PARAMS field in the .env file. These parameters are parsed as a JSON string and integrated into the existing configuration system (config.py/parse_args). The default value for addon_params is set to { "language": "English" }, ensuring no disruption to existing workflows.(my apologies for the linter issues).

Rationale
The addon_params feature addresses the need for greater flexibility and customization in LightRAG's workflows. It allows users to dynamically inject additional parameters, such as language preferences, entity types, or other custom settings, without modifying the core codebase. This is particularly useful for:

Custom Workflows: Tailoring the system's behavior for domain-specific tasks or research experiments.
Dynamic Configuration: Enabling runtime adjustments to configurations without requiring code changes or redeployment.

Limitation
While addon_params is fully supported in LightRAG's core functionality, its usage is limited when using the prepackaged lightrag_server to the default values. I understand that advanced users are encouraged to use the API rather than the prepackaged LightRAG_server, yet I also would like to highlight that it is very user friendly for new users.

By retaining a default value of { "language": "English" }, this feature ensures backward compatibility and does not interfere with existing workflows, making it a seamless enhancement for both new and existing users.

Related Issues

#1239

[Reference any related issues or tasks addressed by this pull request.]

Changes Made

[List the specific changes made in this pull request.]

Checklist

• Changes tested locally
• Code reviewed
• Documentation updated (if necessary)
• Unit tests added (if applicable)

Additional Notes

[Add any additional notes or context for the reviewer(s).]

[danielaskdd]

Could you please provide an overview of the rationale behind implementing the --addon_params transmission? Specifically, what challenges or issues does this feature aim to address?

[3ammari]

Again my apologies for the linting issues.
I added a more detailed description.
Thanks

[danielaskdd]

Thank you for your contribution to the community. While the proposal to enhance addon_params for LightRAG Server users is well-intentioned, exposing these parameters directly via the command line (--addon_params) is not ideal. Doing so would require users to have internal knowledge of LightRAG Server’s implementation details and could introduce compatibility challenges as the addon_params interface evolves.

Instead, we recommend configuring addon_params via environment variables, following the pattern established by SUMMARY_LANGUAGE. This approach ensures better maintainability and backward compatibility.

Additionally, we’ve observed that the current PR disrupts the existing SUMMARY_LANGUAGE environment variable functionality, preventing dependent workflows from operating as intended in the updated version. We kindly request addressing this regression to maintain a seamless user experience.

Please let us know if you have any questions or need further clarification. We appreciate your efforts and look forward to collaborating on this improvement.

[danielaskdd]

We should adhere to the principle that all configurations can be managed through the .env file, eliminating the need to rely on command-line parameters.

[vmahe35]

Finally, is there a way to configure a ADDON_PARAMS env variable, in order to be able to overload the default values of entity types (defined in PROMPTS["DEFAULT_ENTITY_TYPES"]) as well as the list of examples ?
It would be useful, especially in server mode.