Switch PythonTool to use HTTP API instead of gRPC

[JanPokorny]

We can switch to https://github.com/i-am-bee/bee-code-interpreter/blob/main/src/code_interpreter/services/http_server.py to simplify our communication pattern.

This would allow us to say bye-bye to bee-proto entirely.

[mmurad2]

This introduces a breaking change, need to discuss how to rollout

[markstur]

This will require changes in at least 4 repos. So the initial adds in this list need to land first. Then consumers like bee-api and starter can each update to the new framework/tool/port.

• Expose the HTTP ports in bee-stack (code interpreter already has HTTP support) Open port to use code interpreter over HTTP bee-stack#53
• Add unit and e2e tests for the tool feat!: add python code tool over http #195
• Add a new tool (coexist with old tool) feat!: add python code tool over http #195
• Update starter kit to use new framework and port
• Update bee-api to use new framework and port
• Remove the gRPC tool

[Tomas2D]

Please validate @JanPokorny

[JanPokorny]

@markstur Is it necessary to add a new tool for HTTP and let it coexist with the gRPC tool? Why can't we make the switch in the framework and then update the bee-api, bee-ui etc. with the new framework version + new Code Interpreter URL?

Switching would be a breaking change for users that set a custom Code Interpreter URL either way -- and we're on version 0.0.* so this is covered.

[markstur]

@JanPokorny my initial work was to change the framework tool first, but after trying to test it and thinking about how to make the switch I felt like:

1 - just exposing both in bee-stack is an obvious first step PR
2 - having coexisting tools will ease the switch so that bee-api, starter, custom... can each switch to the new tool whenever each separate repo has its PR merged (plus custom code wherever/whenever).

I'd like to flip them all ASAP, but it's not all code in one repo so I'd prefer not to have everything broken on our repos main branches for long. Custom code could continue to work the old way with a pinned framework and can easily move forward if we have coexisting support with just the URL setting.

Perhaps I also choose to pursue this way because I was already seeing main bee-api incompatible with main bee-framework and it makes it hard to test the whole thing. I feel like the order proposed is safest/simplest until all the places are happy with the new way.

But I'm open to shaping those PRs to the maintainers preference.

[JanPokorny]

@markstur bee-api uses a specific version of bee-agent-framework, and the incompatibilities are accounted for together with updating the framework version. Publishing a change in bee-agent-framework does not "break" the other repos -- they all reference specific versions of the framework, newer changes don't take effect until the framework is explicitly updated. So the optimal course is to just make a breaking change in the framework, release a new version, and then adjust the other repos together with updating to the new version.

[markstur]

Understood, but bee-api was already incompatible with main for unrelated reasons so doing this in pieces would've been more mergeable at the time. We can now focus on just getting this all done instead. That'd be great. I've updated so only HTTP is used for the one and only PythonTool.

[markstur]

I got a CustomTool working w/ some e2e tests (not mocks yet), but got interrupted by the holidays and probably won't get that cleaned up for the PR until next week (year!). FYI and darn! and happy new year y'all!