Starting The Implemention For LangChain

[MalikMAlna]

Started small and simple by adding LangChain to the requirements.txt and created an actual main method for running the functionality when we have something more to work with here.

Again, I'm pretty new to LangChain so I'm not 100% on where to get started, but I would like to keep the core implementation to the same file with different agents being added into a separate folder.

Any suggestions would be very much appreciated.

[MalikMAlna]

PR associated with discussion in Issue #150

[MalikMAlna]

Thanks to @Ryangr0 for recommending his main.py file where I found these exception messages.

[Ryangr0]

https://github.com/hwchase17/langchain/pull/2878 FYI @MalikMAlna

[MalikMAlna]

hwchase17/langchain#2878 FYI @MalikMAlna

So does this mean that our work on implementing here is largely pointless?

[moover-shaker]

Same question I asked in issue #150. If we decide to continue, it certainly would make our job a lot easier, esp. todo a full integration. I think there are several issues to consider:

• How much traction is there really in the BabyAGI community to continue and embellish the project? If there was a lot, and if the value to be added outside of LangChain was substantial, then maybe it’s worth continuing. But if not we should stop. Maybe we could take a poll?
• In reading through the pending PRs, most of the requests would be met by a well integrating LC base. Some would not - they mostly pertain to GUI.
• Has the BabyAGI community started work on a good extension API? Could a LC integrated version be tied into that?
• To @Ryangr0 and @MalikMAlna, do you see enough value in our project to continue working on it or not?

One thing to keep in mind is that LC is still a complex framework with no UI. For many use cases, this makes a high friction choice. We need to think about whether a BabyAGI LC integration could significantly reduce that and do it enough to justify the work (and, perhaps, the existence of BabyAGI at all).

look forward to your (and others) thoughts.

[MalikMAlna]

Well @moover-shaker, I do think there is certainly some traction given the largely positive responses to the Issue, but relative to the rest of the community I can’t speak with any certainty. Feel free to set up a poll if you think that would help.

And yeah, I do agree that a lot of the PRs would be resolved with an LC implementation, but if LC is building babyagi in as their Task Orchestration it just seems redundant to do our own implementation here versus building up/out the Task Orchestration within LC itself.

I don’t believe there’s been any work on an API and while an LC implementation could help with that it seems to be coming close to becoming a completely separate project at that point if one is attempting to implement both of those things together.

And honestly any value that still remains in the project could largely be applied to just making the LC implementation more lightweight/useable with some of the suggestions you’ve made for their Task Orchestration.

Regardless of whether an LC implementation is made, I still think there is value in the core architecture and making it more efficient and flexible. Having something relatively lightweight and customizable for autonomous AI will still have its use cases. I just think that the LC implementation largely addresses our initial ideas and any changes one could make to our approach on the implementation could likely serve a better purpose by being added to what’s now already in LC.