feat(go): implement load prompt from source

[josearomeroj]

Usage:

	source := `---
description: Test Prompt
model: test/model
input:
  schema:
    username: string
---
Hello {{username}}`

	p := LoadPromptFromSource(g, source, "testPrompt", "testNamespace")

Checklist (if applicable):

• PR title is following https://www.conventionalcommits.org/en/v1.0.0/
• Tested (manually, unit tested, etc.)
• Docs updated (updated docs or a docs bug required)

[gemini-code-assist]

Summary of Changes

Hello @josearomeroj, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the prompt management capabilities by introducing a new LoadPromptFromSource function. This allows developers to define and register AI prompts programmatically from string content, rather than being limited to loading them from physical files. This change provides greater flexibility for dynamic prompt creation and integration, streamlining the process of working with AI prompts within the application.

Highlights

• New LoadPromptFromSource Function: Introduced a new function to load AI prompts directly from a string source, providing more flexibility than file-based loading.
• Refactored Prompt Registration: Centralized the prompt registration logic into a new internal registerPrompt helper function, improving code reusability and maintainability.
• Enhanced Logging: Updated logging messages to use "source" instead of "file" when referring to prompts loaded from string sources, providing more accurate context.
• Comprehensive Testing: Added new unit tests to validate the functionality of LoadPromptFromSource, including handling of prompt variants and rendering.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new feature to load prompts from a string source, which is a valuable addition for programmatic prompt creation. The implementation includes a good refactoring that consolidates prompt registration logic, improving code maintainability. The new functionality is also exposed through the public genkit package. My review includes suggestions to enhance test coverage by adding test cases for invalid prompt sources, which will help ensure the robustness of the new feature.

[gemini-code-assist]

The test for TestLoadPromptFromSource is great for the happy paths. To make it more robust, consider adding a test case for when an invalid prompt source is provided. This will ensure that the function correctly handles errors and returns nil as expected.

For example, you could add a check for a source with an unclosed template variable.

Suggested change

	}
	}
	}
	// Test invalid source
	invalidSource := "---\ndescription: Invalid\n---\nHello {{ name" // unclosed template variable
	pInvalid := LoadPromptFromSource(reg, invalidSource, "invalidPrompt", "testNamespace")
	if pInvalid != nil {
	t.Error("LoadPromptFromSource with invalid source should have returned nil")
	}
	}

[josearomeroj]

We cannot add a test case that expects LoadPromptFromSource to return nil for invalid template syntax (like an unclosed variable) because the underlying dotprompt library performs parsing loosely at load time. It does not validate the template syntax during Parse, so LoadPromptFromSource successfully returns a Prompt object. The error would only occur later during execution (e.g., when Render is called).

[gemini-code-assist]

This test covers the successful creation of a prompt. It would be beneficial to also test the failure case, for instance, when the provided source is invalid. This ensures the wrapper function correctly propagates the nil return on error.

Suggested change

	}
	}
	}
	// Test invalid source
	invalidSource := "---\nmodel: test/model\n---\nHello {{ name" // unclosed template variable
	pInvalid := LoadPromptFromSource(g, invalidSource, "invalidPrompt", "testNamespace")
	if pInvalid != nil {
	t.Error("LoadPromptFromSource with invalid source should have returned nil")
	}
	}

[apascal07]

Can I ask what your use case for this is? Why not define a prompt programmatically with strong types, etc?

[josearomeroj]

Can I ask what your use case for this is? Why not define a prompt programmatically with strong types, etc?

I need this to treat prompts as dynamic data by loading them from an external databas at runtime, also enables the use of go:embed strings to register prompts directly from embedded files.

[apascal07]

Can I ask what your use case for this is? Why not define a prompt programmatically with strong types, etc?

I need this to treat prompts as dynamic data by loading them from an external databas at runtime, also enables the use of go:embed strings to register prompts directly from embedded files.

Got it. FYI, we are adding embed support: #3973

Let me consider this, we'll either get this PR in or something else that works for you by the next release. Thanks for your contribution!