feat: support for automatic update KCL dependencies on kcl.mod file save

[octonawish-akcodes]

• Added a new function watch_kcl_mod to monitor changes to the kcl.mod file and trigger dependency updates accordingly.

• Added a separate kcl_mod_file_track function that can be called from the LSP implementation(yet to be explore)

I want to know what target folders can be used for the calling of this kcl_mod_file_track

Related Issue #998

cc @Peefy @zong-zhe @He1pa

[Peefy]

I think from a technical architecture perspective, this should be a more universal build system that can be used not only to monitor changes in kcl.mod files, but also to monitor changes in other files in the KCL ecosystem (*.k even if *.yaml, *.json). What do you think of these things when it comes to creating the kcl build -- watch command in the end? cc @He1pa @octonawish-akcodes

[octonawish-akcodes]

What is the scope of this kcl build -- watch, I mean what usability will it provide to the KCL user can you elaborate a bit?

[Peefy]

In summary, kcl build --watch maybe KCL compiler's watch mode, which helps developers to compile KCL code in real-time and receive prompt feedback. This is particularly useful for rapid iteration during development and continuous integration.

That is to say, I believe that the PR should not only watch the kcl.mod file, as such code does not have good scalability. It should be a part of the entire watch system.

[coveralls]

Pull Request Test Coverage Report for Build 8243675034

Details

• 0 of 66 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.08%) to 71.828%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
kclvm/driver/src/kpm.rs	0	66	0.0%

Totals
Change from base Build 8242468454:	-0.08%
Covered Lines:	44677
Relevant Lines:	62200

---

💛 - Coveralls

[octonawish-akcodes]

In summary, kcl build --watch maybe KCL compiler's watch mode, which helps developers to compile KCL code in real-time and receive prompt feedback. This is particularly useful for rapid iteration during development and continuous integration.

That is to say, I believe that the PR should not only watch the kcl.mod file, as such code does not have good scalability. It should be a part of the entire watch system.

hmm, that's a good suggestion tho, we can try to add that in parts like first the flag implementation and then the corresponding implementation of functionalities. Not sure about the real-time running of kcl package(did you meant after every change in the file kcl run should get triggered?)

[Peefy]

I suggest first providing the tech design of the Watch System, including an explanation of its scalability, how to extend kcl. mod files, how to access more file types such as JSON, YAML, and the watch system APIs, etc., without the need to first implement flags.

[octonawish-akcodes]

I suggest first providing the tech design of the Watch System, including an explanation of its scalability, how to extend kcl. mod files, how to access more file types such as JSON, YAML, and the watch system APIs, etc., without the need to first implement flags.

Should I start a new discussion in the discussion topics or add a new design in the docs and raise a PR?

[Peefy]

I suggest first providing the tech design of the Watch System, including an explanation of its scalability, how to extend kcl. mod files, how to access more file types such as JSON, YAML, and the watch system APIs, etc., without the need to first implement flags.

Should I start a new discussion in the discussion topics or add a new design in the docs and raise a PR?

Yes.

[Peefy]

I will merge the PR, this is just a simple first step. The subsequent design and implementation need to be combined with the watch system, file system, and language server to clarify the technical architecture. cc @zong-zhe @He1pa