Is it possible to use this without langchain?

[ntindle]

I have a specific use case that would be enabled, but it doesn't support langchain and probably won't for the foreseeable future.

It seems this has a hard dependency on langchain in the requirements.txt, but I'd like to know if that can be removed
or swapped out.

[drazvan]

Hi @ntindle! What do you mean by "it doesn't support langchain"? Are you saying that for your use case you are not allowed to have langchain as a dependency?

[ntindle]

Yeah exactly! We're working on a project that can't use langchain as a dependency.

Our use case would be wrapping responses from various local and non local LLMs to apply some level of safety to users interacting with various LLMs

[drazvan]

Unfortunately, it is not possible to remove the langchain dependency. However, the core nemoguardrails functionality only uses a limited set of features from langchain e.g. PromptTemplate, LLMChain and LLM implementations. We are currently not aware of any vulnerabilities from langchain that would propagate to nemoguardrails. Is there something in particular about langchain that makes it unusable for your use case?

[ntindle]

There are a handful of critical things that cause problems with langchain. The main being Auto-GPT proceeds many of their implementations, and their architecture choices do not fit our use case.

I'll pass a few of the comments around our discussions. I've omitted some parts and edited others so it is more suitable for the public. I've also removed meaningful context around these discussions, but if you'd like to join our discord or schedule a chat to get that context, I'd be happy to facilitate.

I have spent much time lately using and evaluating Lang Chain. On the surface, it seems pretty cool, and on a surface level, it is if you're ok with the trade-off of using canned examples vs. process time. It's pretty easy to get something basic setup, it runs slow, though, and once you get beyond the basic stuff, it gets overly complicated and embodies some of the worst parts of objective programming. Between classes of the same type, there needs to be more consistency. It's a customizable framework if the customization you want is an example or use case they provided. In theory, you could build from the ground up using the custom classes, but if you're going to do that, what do you need the framework for? The same goes for all of its classes. And it's not quick or easy to spring up an agent for temporary use. It's a pain in the ass to do from a programming perspective. It also acts as a wrapper for some of the other packages in 'integrates,' in doing so, you lose the ability to use some of the original usability of the original packages. Lastly, it has a lot of shit going on under the hood, probably too fucking much, and its documentation is [not excellent]

It's been decided that our arch won't be Langchain dependent, but sections of it may optionally use langchain primitives if it makes sense

Overall, langchain doesn't fit our use case or architecture for Auto-GPT. Adding it as a core dependency is a non-starter for us, but the tool you built here IS useful and would enable a lot of confidence in supporting local LLMs for our Auto-GPT.

[ntindle]

Let me clarify a bit, Auto-GPT isn't built to use langchain's llm functionalities, but does use other functionalities from langchain such as the tools