Fixes #46

[dangoldner]

datetime.date arguments can't be inferred by inspection so must be handled as custom types.

[jph00]

I don't quite follow this PR, sorry! It seems that dateArg is defined twice, but never used, IIUC?

[dangoldner]

• dateArg is now defined once (as you might guess, I had both the nbdev and solveit export flags set)
• Like PathArg, dateArg is not called by the code directly anywhere, but it shows up in the schema to convert the json (string) argument to the correct custom type. The pre-existing notebook section on Path explains this for experts, or see this dialogue for an explanation for newcomers.
• It was cool to learn what I needed to add this, but should it be added? Tools with date-type arguments could easily be rewritten to take string arguments and convert them inside the tool code. You may or may not want a burgeoning set of custom types (this PR would double the number, to two). Of course the same is true for Path, and Path is in here. No hard feelings either way :)
  See below

[dangoldner]

There's something I still don't understand so pulling this back to draft for now ...

[dangoldner]

This PR started out to allow date-type parameters in tool functions. But I learned that the pre-existing support for Path-type parameters was incomplete:

• get_schema was correctly including information needed to convert paths from json strings to Path objects, but
• custom param types (e.g. PathArg) were not being added to the custom_types watch list, and
• no conversion was happening prior to the actual tool call.

So now, this PR simply fixes the situation for Path types.

I will wait to submit a separate PR for dates until Paths are merged and working correctly.

[dangoldner]

Ok, git PRs and nbdev both new to me so apologies for the scattered commits, but I think we're now good to go.

[jph00]

Thanks!

[jph00]

Sorry I actually reverted it, since on reflection fixing this properly required a bit more machinery, and a proper e2e test. Path should work fine now I believe.