feat: Google Calendar Tool (wip)

[nickscamara]

Functionality:

• Create event
• View event
• View events
• Delete event
• Reschedule event

Docs:

• Google calendar, create event example
• Google calendar ecosystem (not using load_tools yet)

Tests:

• Simple test for creating event

I removed from load_tools for now, cause not sure if belongs there yet.
Instructions:

• Follow instructions here: https://developers.google.com/calendar/api/quickstart/python
• When you run for the first time, you will need to authenticate OAuth w/ Google

[hwchase17]

high level the functionality looks good, but i create a distinction between (1) the wrapper around google cal, and (2) the chain that goes LLM -> google cal API (eg run and run_create_event). i would keep (1) where it is, and move (2) into langchain.chains module

[nickscamara]

Got it. I also agree that separating it more would be better. Although I have some doubts about how this could look like.

1 - Would the run method of the Calendar tools look something like this? Where the wrapper doesn't handle the call to google API and where LLMGoogleCalendarChain handles classification and run_events.

    def run(self, query: str) -> str:     
        google_calendar_chain = LLMGoogleCalendarChain(
            ...,
            query=query,
        )
        return google_calendar_chain.run(query)

• If so, wouldn't the wrapper tool lose its purpose of being a wrapper as most of the google API logic will be in the chain itself?

or

The other option I see is that the wrapper is the one that should be calling the google API.
That way it uses the chain to get the output in the right format then it uses the wrapper again to make the call to google API. Which I think makes more sense. Although, the chain wouldn't have access to the google API.

or

Maybe there should be better separation between wrappers and tools? But not sure about this one.

Let me know your thoughts :)

[hwchase17]

@nickscamara the way i was thinking about it was that nothing that required an LLM should be in the Gcal Utility Wrapper. Eg it would just be create_event, list_events, etc - eg all the methods that interact with Gcal in a deterministic manner

everything that required an LLM would go in the chain class

[dgde]

This looks very promising, any new progress here at all? @nickscamara

[libratiger]

just want to know is there any progress ? @nickscamara

or is there any type to support the common Calendar type ? @hwchase17

[dev2049]

@vowelparrot we don't have anything for gcal yet right?

[vowelparrot]

@vowelparrot we don't have anything for gcal yet right?

Not yet in core :) this would be a good one to add. I likely won't get around to it until at least this weekend though

[rwhiten1]

Hi I have actually been working on a GCal client to so I could make a custom tool for a proof of concept. Then I decided to look and see if anything GCal related was in-flight and found this. Is there any way I could help get this one across the line?

[prodineeritecht]

I am the same person as @rwhiten1 , that is an older github account and wanted a fresh start in a new account so I created @prodineeritecht a while ago, but am just now getting around to using it. I'll gladly help get this across the line but had a question for @nickscamara , @vowelparrot , and @hwchase17. When I was looking through the langchain repository, I noticed that gmail was actually created as separate tools for each of the gmail functions, and that pattern seems to make the most sense to me. Do any of you have a problem if I were to refactor this PR or create a new PR to follow that pattern? Also, while I've been an SE for a good long while, I'm still something of a Python noob (scala, java, C# were my main languages) so if I push up anything that goes against Python best practices, let me know and I will gladly change it. I'm also currently between jobs so I have plenty of time to get this all working. I feel like I could have it ready to go either at the end of the week or early next week. Thanks!

[eyurtsev]

Closing as stale