Adds composio-weaviate

[CShorten]

Important

Adds composio-weaviate plugin to integrate Composio with Weaviate, enabling data querying using Composio tools.

• New Plugin:
  • Adds composio-weaviate plugin to integrate Composio with Weaviate.
• Core Functionality:
  • Introduces ComposioToolSet class in toolset.py to wrap Composio tools for Weaviate.
  • Implements connect_to_weaviate() and run_query() methods for Weaviate connection and querying.
• Deprecation:
  • Deprecates get_actions() in favor of get_tools() in toolset.py.
• Setup:
  • Adds setup.py for plugin configuration with dependencies on weaviate-client, weaviate_agents, and composio_core.
• Documentation:
  • Adds readme.md with a brief description of the integration.

^{This description was created by for 3a63ed7. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
composio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 1, 2025 7:37pm

[entelligence-ai-pr-reviews]

The connect_to_weaviate() method does not validate that required credentials are provided, allowing connection attempts with missing credentials that will fail at runtime

📝 Committable Code Suggestion

‼️ Ensure you review the code suggestion before committing it to the branch. Make sure it replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

	cluster_url = cluster_url or os.environ.get("WEAVIATE_URL")
	api_key = api_key or os.environ.get("WEAVIATE_API_KEY")
	openai_api_key = openai_api_key or os.environ.get("OPENAI_API_KEY")
	collections = collections or ["Blogs"]
	cluster_url = cluster_url or os.environ.get("WEAVIATE_URL")
	if not cluster_url:
	raise ValueError("WEAVIATE_URL is required but not provided")
	api_key = api_key or os.environ.get("WEAVIATE_API_KEY")
	if not api_key:
	raise ValueError("WEAVIATE_API_KEY is required but not provided")
	openai_api_key = openai_api_key or os.environ.get("OPENAI_API_KEY")
	if not openai_api_key:
	raise ValueError("OPENAI_API_KEY is required but not provided")
	collections = collections or ["Blogs"]

[entelligence-ai-pr-reviews]

The get_tools() method does not validate that processors is a valid type before attempting to merge, which could cause runtime errors

📝 Committable Code Suggestion

‼️ Ensure you review the code suggestion before committing it to the branch. Make sure it replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change

	if processors is not None:
	self._processor_helpers.merge_processors(processors)
	if processors is not None and isinstance(processors, (list, dict)):
	self._processor_helpers.merge_processors(processors)

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 3a63ed7 in 2 minutes and 36 seconds

More details

• Looked at 302 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 10 drafted comments based on config settings.

1. python/plugins/weaviate/composio_weaviate/toolset.py:129

• Draft comment:
  Ensure 'self.entity_id' is properly initialized before use.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
  The comment is asking the author to ensure that 'self.entity_id' is properly initialized before use. This is a general reminder and not a specific suggestion or question about the code. It doesn't provide a specific code suggestion or ask for a test to be written. It falls under the category of asking the author to double-check something, which is against the rules.

2. python/plugins/weaviate/composio_weaviate/toolset.py:210

• Draft comment:
  Verify that '_processor_helpers' is defined in the class or its parent.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the PR author to verify something, which is against the rules. It doesn't provide a specific suggestion or point out a clear issue. Therefore, it should be removed.

3. python/plugins/weaviate/setup.py:26

• Draft comment:
  Consider using version ranges for dependencies to improve compatibility.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

4. python/plugins/weaviate/composio_weaviate/__init__.py:14

• Draft comment:
  Consider adding a trailing newline at the end of the file for POSIX compatibility.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

5. python/plugins/weaviate/composio_weaviate/toolset.py:124

• Draft comment:
  Consider using functools.wraps to automatically preserve metadata (e.g., name and doc) for the inner wrapper function.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The code is doing very specific function creation with custom signature handling and metadata assignment. functools.wraps is designed for simpler decorator patterns. Here they need precise control over the function creation process, including custom signature creation from schema params. Using functools.wraps would likely interfere with this custom behavior and wouldn't handle the schema-based signature creation.
  Perhaps functools.wraps could be used in combination with the custom logic to make the code more maintainable. The current approach might miss copying some metadata that wraps handles automatically.
  The custom function creation is necessary for the schema-based tooling system. functools.wraps would add complexity without benefit since we need explicit control over signature, name and docs based on schema data.
  The comment should be deleted. The current implementation requires specific control over function creation that functools.wraps would complicate rather than improve.

6. python/plugins/weaviate/composio_weaviate/toolset.py:133

• Draft comment:
  Using globals=globals() when creating the new function may capture unintended variables. Consider providing a more restricted globals dictionary if possible.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50%
  The comment raises a valid security concern - passing the entire globals() namespace could expose unintended variables to the generated function. However, the function being created needs access to self.execute_action and Action from the global scope to work properly. Simply restricting to builtins would break the functionality. The suggested change would make the code non-functional.
  I could be wrong about what globals are actually needed by the generated function. Maybe there's a way to provide just the minimal required globals.
  Looking at the function body, it definitely needs access to self.execute_action and Action at minimum. The suggested change would break this core functionality.
  While the comment raises a valid concern, the suggested fix would break the code. The current implementation, while not ideal, appears necessary for functionality.

7. python/plugins/weaviate/readme.md:3

• Draft comment:
  Consider expanding the documentation with more detailed usage examples and setup instructions to improve developer onboarding.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50%
  None

8. python/plugins/weaviate/setup.py:10

• Draft comment:
  Consider specifying packages (e.g., using packages=find_packages()) in the setup configuration to ensure all submodules are included in the distribution.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50%
  This is a new setup.py file and missing packages configuration could cause issues with package distribution. However, without seeing the actual package structure, I can't be 100% sure if there are submodules that need to be included. The comment seems reasonable but speculative without more context. Following our rules, we should err on the side of deletion if we're not certain.
  I might be overly cautious - missing package configuration could cause real distribution issues. The comment provides a specific, actionable solution.
  While the suggestion might be helpful, we don't have enough context about the package structure to be certain it's needed. Our rules state we should have strong evidence to keep comments.
  Delete the comment since we don't have strong evidence that submodules exist that need to be included, making this suggestion speculative.

9. python/plugins/weaviate/setup.py:31

• Draft comment:
  Add a trailing newline at the end of the file for consistency and POSIX compliance.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

10. python/plugins/weaviate/setup.py:31

• Draft comment:
  Trivial: Consider adding a newline at the end of the file to adhere to file formatting best practices.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  While having a trailing newline is indeed a common best practice, this kind of formatting issue is typically handled by code formatters and linters. It's a very minor issue that doesn't affect functionality. The comment uses the word "Trivial" which acknowledges this. Most modern IDEs and build systems would automatically handle this.
  The comment is technically correct about best practices. Missing trailing newlines can cause issues with some Unix tools and make diffs less clean.
  While technically correct, this is exactly the kind of minor formatting issue that should be handled by automated tools rather than manual code review comments. It's too trivial to warrant human attention.
  Delete this comment as it's too trivial and would typically be handled by automated formatting tools rather than manual review.

Workflow ID: wflow_PG60ePEyTpOXDtAZ

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

Consider adding error handling if WEAVIATE_URL, API keys are missing.

[ellipsis-dev]

Please add a newline at the end of the file.

Suggested change

	)
	)\n

[shreysingla11]

Consider adding validation for required environment variables before attempting connection. This would provide clearer error messages:

def connect_to_weaviate(self, cluster_url=None, api_key=None, openai_api_key=None, collections=None):
    cluster_url = cluster_url or os.environ.get("WEAVIATE_URL")
    if not cluster_url:
        raise ValueError("Weaviate cluster URL not provided and WEAVIATE_URL environment variable not set")
    
    api_key = api_key or os.environ.get("WEAVIATE_API_KEY")
    if not api_key:
        raise ValueError("Weaviate API key not provided and WEAVIATE_API_KEY environment variable not set")
    
    openai_api_key = openai_api_key or os.environ.get("OPENAI_API_KEY")
    if not openai_api_key:
        raise ValueError("OpenAI API key not provided and OPENAI_API_KEY environment variable not set")

This would help users identify missing configuration more easily.

[shreysingla11]

Consider adding return type hints to the method for better code clarity:

def connect_to_weaviate(self, cluster_url=None, api_key=None, openai_api_key=None, collections=None) -> 'ComposioToolSet':

This makes it clear that the method supports method chaining.

[shreysingla11]

Consider adding basic error handling for Weaviate connection:

try:
    self.weaviate_client = weaviate.connect_to_weaviate_cloud(
        cluster_url=cluster_url,
        auth_credentials=Auth.api_key(api_key),
        headers={
            "X-OpenAI-Api-Key": openai_api_key
        }
    )
except Exception as e:
    raise ConnectionError(f"Failed to connect to Weaviate: {str(e)}")

This would help catch and report connection issues more clearly.

[shreysingla11]

The readme.md is quite minimal. Consider expanding it with:

• Installation instructions
• Configuration options and environment variables
• More detailed usage examples
• Common use cases
• Troubleshooting section

This would make it easier for users to get started with the plugin.

[shreysingla11]

Overall Review:

The PR adds a well-structured Weaviate integration to Composio. The code is generally well-written with good documentation and type hints. Here are the key points:

Strengths:
✅ Clean integration with Weaviate's QueryAgent
✅ Good docstrings and example usage
✅ Proper type hints throughout the code
✅ Clean separation of concerns
✅ Good error handling in query execution

Suggestions for improvement:

1. Add validation for required environment variables
2. Add return type hints for better code clarity
3. Enhance error handling for Weaviate connection
4. Expand the readme.md with more comprehensive documentation

The code is production-ready with the suggested improvements. The integration will be valuable for users wanting to combine Composio's tools with Weaviate's vector database capabilities.

Rating: 8/10 - Good quality code with room for minor improvements in error handling and documentation.

[CShorten]

Hey team, it would be great if we could get this across the line. Great way to integrate with Agent ecosystem

-- cc @erika-cardenas @hsm07