Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 howSummaryGenerator
is in a module that no longer importssuper_agi
. It actually doesn't need to importlangchain
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.