Prompts: Add Save and FromFile functions to serialize/deserialize prompts to disk

[cduggn]

PR Checklist

• Read the Contributing documentation.
• Read the Code of conduct documentation.
• Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
• Describes the source of new concepts.
• References existing implementations as appropriate.
• Contains test coverage for new functions.
• Passes all golangci-lint checks.

Description

This PR adds the ability to serialize and deserialize (some) prompt templates to and from disk. This is useful for sharing, storing, and versioning prompts. It supports JSON and YAML formats.

• As part of this PR the prompt.FormatPrompter interface was updated to include a Save function

The prompt types supported in this initial PR include the following with conditions.

• PromptTemplate : supports Save and creation FromFile
• HumanMessagePromptTemplate : supports Save and creation FromFile
• SystemMessagePromptTemplate: supports Save and creation FromFile
• GenericMessagePromptTemplate : not used explicitly however it does implement the MessageFormatter interface and as such it was necessary to provide an implementation of Save
• AIMessagePromptTemplate: same as GenericMessagePromptTemplate this is not called explicitly however due to its contract with the MessageFormatter interface I have also provided an implementation of Save

Existing Implementation

Serialization for prompt templates is available in the upstream Python version of the library in the following packages:

• Load
• dump

[tmc]

I'm not sure we should be in the business of wrapping serialization like this -- Go has great yaml and json support and folks may want their own formats and encodings.

Unless the langchain community comes up with some langchain-specific types of encoding I'm not sure it's worth it for us to wrap serialization in this manner.

Go encourages programming to the io.Reader and io.Writer interfaces which keeps code agnostic to underlying transport or storage concerns and I think we should embrace that and not address these concerns in this codebase.

[tmc]

I'm skepitcal we need this abstraction, the go stdlib has plenty of good filesystem io primitives and if anything adding this will constrain users of this code.

[cduggn]

fair enough, I was looking at this myopically, considering load package only. I'll revert the filesystem abstraction

[cduggn]

@tmc I've removed the io package abstraction. There is a minimum set of prompt types supported with this PR, which doesn't include chatprompttemplate . It has a more complex interface structure. It's probably not suitable to leave an unimplemented function in the code . I can close the PR if this is not desirable

func (p ChatPromptTemplate) Save(path string) error {
	_ = path
	return ErrNotImplemented
}

[cduggn]

going to close this for now and revisit with a more succint commit history