This draft PR starts the refactor process. The idea is that we can decouple the logic from SuperAGI. This is done by having logic passed into classes rather than then being based off of the SuperAGI logic.
An example of this is in summary_generator.py. You can see how SummaryGenerator is in a module that no longer imports super_agi. It actually doesn't need to import langchain either - it has some default chat logic that uses it for convenience but really doesn't need it.
There's an issue with how the superagi toolkit is a separate dependency than superagi itself. The way that python works is that if you have a module to import, it'll import the first valid name it comes across in its list of locations to search. There's a known consternation around this when you decide to stuff submodules under the same namespace but install them in different locations. I believe there's a technique to work around this, but it doesn't appear superagi is doing this. As a result, the codespace has superagi in two locations - one is in the library path for the virtual environment, which is looked at first. This contains the toolkit logic. The other path is under /workspaces/SuperAGI and this contains everything else. Python does the first import, then assumes that submodules that are missing in that import nowhere else to be found.
I've seen this issue before when using Google's Python library. Specifically, they had separated out their gRPC logic from app engine and this created problems because you had vendored google libraries but also built-in google libraries.
My suggestion at this time is to just live with this issue because the proper fix, I think, would be in SuperAGI. Since we're doing a refactor that decouples things for our unit tests, we can avoid importing from superagi anyways.
This draft PR starts the refactor process. The idea is that we can decouple the logic from SuperAGI. This is done by having logic passed into classes rather than then being based off of the SuperAGI logic.
An example of this is in
summary_generator.py. You can see howSummaryGeneratoris in a module that no longer importssuper_agi. It actually doesn't need to importlangchaineither - it has some default chat logic that uses it for convenience but really doesn't need it.There's an issue with how the superagi toolkit is a separate dependency than superagi itself. The way that python works is that if you have a module to import, it'll import the first valid name it comes across in its list of locations to search. There's a known consternation around this when you decide to stuff submodules under the same namespace but install them in different locations. I believe there's a technique to work around this, but it doesn't appear superagi is doing this. As a result, the codespace has
superagiin two locations - one is in the library path for the virtual environment, which is looked at first. This contains the toolkit logic. The other path is under/workspaces/SuperAGIand this contains everything else. Python does the first import, then assumes that submodules that are missing in that import nowhere else to be found.I've seen this issue before when using Google's Python library. Specifically, they had separated out their gRPC logic from app engine and this created problems because you had vendored google libraries but also built-in google libraries.
My suggestion at this time is to just live with this issue because the proper fix, I think, would be in SuperAGI. Since we're doing a refactor that decouples things for our unit tests, we can avoid importing from superagi anyways.