feat: Tool openapi integration

[vblagoje]

Why:

Creates Tool instances from OpenAPI specifications, enabling the invocation of tools based on OpenAPI JSON or YAML formats.

What:

• Introduced the from_openapi_spec class method in the Tool class, enabling tool creation from OpenAPI specifications provided as URLs, file paths, or string content.
• Added OpenAPIKwargs TypedDict to encapsulate configuration options for OpenAPI integration, including API credentials and allowed operations.
• Uses https://github.com/vblagoje/openapi-llm/ library that is essentially eviscerated code from the former OpenAPITool

How can it be used:

• To create tools with OpenAPI specifications:

from haystack_experimental.components.tools.openapi import create_tools_from_openapi_spec

tools = create_tools_from_openapi_spec(
            spec="https://bit.ly/serperdev_openapi",
            credentials="your-api-key-here"
)
# now you can use tools just like any other Haystack tool

• Supports various methods for importing OpenAPI specifications, making it easy to manage different sources of API definitions.
• Ensures customizable invocation of API endpoints through dynamically generated tool definitions based on the OpenAPI schema.

How did you test it:

• Conducted unit tests that validate the from_openapi_spec method's functionality and verify that tool attributes align with the OpenAPI definitions.
• See the notebook
• More tests soon to be added

Notes for the reviewer:

• Pay special attention to the implementation of the from_openapi_spec method to ensure comprehensive handling of various input types (URLs, file paths, string content).

[coveralls]

Pull Request Test Coverage Report for Build 12434882747

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.07%) to 83.267%

---

Totals
Change from base Build 12422960154:	0.07%
Covered Lines:	2095
Relevant Lines:	2516

---

💛 - Coveralls

[vblagoje]

Before I add more tests @anakin87 please have a look to see if you like the general direction of this approach. I've designed it to require minimal plug-in point to our new Tooling cc @julian-risch @Amnah199

[anakin87]

In general, I like this lightweight approach (mostly due to the fact that we are moving the logic to an external library).

Before moving on, I'd like @julian-risch to take a look.

[anakin87]

In general, I see that offloading most of the logic in Vladimir's library results for us in less maintenance effort (and I am happy about that).
Nevertheless, I see some risks. @julian-risch what's your take on this aspect?

[anakin87]

Differently from @from_function class method, this method returns a list of Tools.
Calling Tool.from_openapi_spec and getting a list of Tools seems a bit confusing from a semantic point of view.

Maybe is it better to create a function (not a class method): something like create_tools_from_openapi_spec.
WDYT? Do you have better ideas?

[vblagoje]

Yeah, good point. I also see a separatecreate_tools_from_openapi_specfunction as a viable alternative but let me see if there is even better approach.

[anakin87]

This utility function only ensures compatibility between Haystack and the new library. I don't expect to use it elsewhere in Haystack if we do things right.
Could it be moved to the library?

[vblagoje]

Good point. I'll move it.

[vblagoje]

Refactored it @anakin87 @julian-risch

[vblagoje]

Circular dep between these two otherwise

[vblagoje]

Here is another idea to think about if we are to follow the Tool.from pattern. This method requires openapi spec and operation name and creates only one Tool just like other from methods. Just an idea....