Use schema format over type

[philippeitis]

This is a draft PR which includes the basic fix, allowing more values to be deserialized correctly.

To handle Google specific types, I've included a rudimentary implementation for base64 and Duration encode/decode.

The Duration struct can simply be imported where necessary, and implements serde directly.
However, the base64 encoding / decoding requires custom attributes to utilize the appropriate serde functions (as we'd want it to be Vec<u8>).

This leaves 3 date-time types, and one fieldmask type. Unfortunately, it is somewhat difficult to track down the concrete type definitions, so I'm not entirely confident that the implementations thus far are correct.

However, I think this go package might be relevant: https://pkg.go.dev/google.golang.org/protobuf/types

(Incidentally, it would be nice to support protobuf APIs for supported endpoints - something I'd like to look at in the future)

PR for #377

[philippeitis]

I've identified that the JSON representation for google-datetime and datetime follows RFC3339, which chrono implements serde for. date is simply a truncated version of RFC3339, and also parsed by chrono.

I've managed to use chrono::Duration for google-duration, with custom serde implementations.

I can't find a source which states that byte is universally representated as url-safe base64.

The last type is google-fieldmasks, but this is a lower priority for me.

I also need to update the generated READMEs to use the correct constructors.

[philippeitis]

That should be all of the previously unsupported types, with appropriate unit tests and example types. While I still want to do some testing on actual API calls, this PR should be mostly ready to go.

I've included some links / information about where I found type descriptions/definitions in util.py, but I'm happy to put these links somewhere else.

[Byron]

Thanks a lot for your incredible effort, they are, as always, much appreciated!

I glanced at the changes and they looked alright, while running make cargo-api ARGS=check in the background. It stopped at accesscontextmanager1 with:

    Checking google-accesscontextmanager1 v4.0.4+20220301 (/Users/byron/dev/github.com/Byron/google-apis-rs/gen/accesscontextmanager1)
error[E0277]: the trait bound `FieldMask: Clone` is not satisfied
   --> src/api.rs:957:5
    |
950 | #[derive(Default, Clone, Debug, Serialize, Deserialize)]
    |                   ----- in this derive macro expansion
...
957 |     pub update_mask: Option<client::FieldMask>,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for `FieldMask`
    |
    = note: required because of the requirements on the impl of `Clone` for `std::option::Option<FieldMask>`

Can you reproduce this and maybe get it to run through on all APIs as well? Then I'd think a merge shouldn't be far.

I've included some links / information about where I found type descriptions/definitions in util.py, but I'm happy to put these links somewhere else.

To me this location seems like a great starting point and it felt intuitive to read them there. I'd keep them there until there is demand for a change or a vastly better place is presenting itself.

Thanks a lot!

[philippeitis]

I've managed to get make cargo-api ARGS=check to compile everything successfully. A few things to note:

1. I've added a dependency on serde_with to support types with arbitrary (de)serialization needs (eg. Option<HashMap<String, client::chrono::Duration>>) - without serde_with, I'd have to either introduce a wrapper type for Vec<u8> and client::chrono::Duration, which would add friction to the API, or add additional modules to support every special type that occurs - which requires manual updates when the API changes.
2. I've introduced a rust_type.py file: this is used in conjunction with serde_with to support all arbitrary types - the RustType class provides functionality for providing the appropriate serde_with type and indicating if special serialization support is necessary.
3. I've introduced code to use the correct to_string implementation for parameter types - this is necessary to support Vec<u8> as urlsafe-base64, and to use the correct string format for datetimes and durations.

[Byron]

This is amazing work! I'd even call it 'magical' as I always have trouble wrapping my head about serde internals, yet you seem to bend it to your will!

Introducing serde-width seems like a good choice and is well worth the added dependency. By now you are the authority on the type-system in these crates, and I don't claim to understand it anymore remembering only that back in the days when I wrote it, I just 'hammered' it to work well enough and called it a day. Now it seems more sophisticated and capable than ever, many thanks for that!

If you would ever be open to a maintainer role in this project, I'd be happy to send you an invite.

[Byron]

drive3 v5.0 was released as a sample crate. My plan is to iterate on it or other samples until the code is proven to work well enough and then release all crates as v5.0. As I am not using any of the crates myself I will rely on feedback to determine the 'all-in' release date. Thanks.