let Enums be actual rust Enums & split into modules

[OMGeeky]

I found it quite impractical to always look up what options are available for each enum & pass the as strings, so I created this PR which turns the enums provided by the API into enums in Rust.
During this whole thing I had some problems with the file being quite large and my IDE struggling to not lag all the time, so I separated the individual parts into modules, which were currently only separated by a comment.

With this I can for example use

VideoStatusPrivacyStatusEnum::Private

instead of
private
for the YouTube-API and actually get compiler errors when i misspelled something.

Note that I appended Enum to each enum name to reduce collisions with other existing types etc.

I am open to Ideas and willing to put some time into this if any changes need to be made.

[OMGeeky]

I think I got most of the issues fixed. Currently I'm stumbling over a build error in bigtableadmin2 where there is a struct containing itself, which isn't allowed directly since it cannot calculate its size. The nested struct needs to be a reference or Box or something like that.

This is the error:

    Checking google-bigtableadmin2 v5.0.5+20240331 (/home/omgeeky/Rust/google_drive/google-apis-rs/gen/bigtableadmin2)
error[E0072]: recursive types `GoogleBigtableAdminV2TypeAggregate` and `Type` have infinite size
    --> src/api.rs:1067:1
     |
1067 | pub struct GoogleBigtableAdminV2TypeAggregate {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
1071 |     pub input_type: Option<Type>,
     |                            ---- recursive without indirection
...
1967 | pub struct Type {
     | ^^^^^^^^^^^^^^^
...
1971 |     pub aggregate_type: Option<GoogleBigtableAdminV2TypeAggregate>,
     |                                ---------------------------------- recursive without indirection
     |
help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle
     |
1071 ~     pub input_type: Option<Box<Type>>,
1072 |     /// Output only. Type that holds the internal accumulator state for the `Aggregate`. This is a function of the `input_type` and `aggregator` chosen, and will always specify a full encoding.
   ...
1970 |     
1971 ~     pub aggregate_type: Option<Box<GoogleBigtableAdminV2TypeAggregate>>,
     |

For more information about this error, try `rustc --explain E0072`.
error: could not compile `google-bigtableadmin2` (lib) due to 1 previous error

and the same one is also happening on the main branch, so its not from my changes.

One thing that is from my changes is that the values can no longer just be passed in as a string. They need to be converted to an enum if they really need to be strings or just be enums.
That is a breaking change, but in my opinion its worth it and I got no good Idea how to not create a breaking change at that specific point. The only way I could think of would be to make the method definitions generic accepting an Into<Enum> (or TryInto<Enum> since not all string values can be converted and would get the program to panic if invalid), but I can't think of a good way to change the method signature so it works.

These issues currently causes the CLIs not to build.

[Byron]

It's interesting you are encountering the issue with bigtableadmin2 as failing APIs are usually ignored entirely. Since it's on main, and if it prevents me from releasing the crates, I'd just put it onto the ignore-list.

Regarding the API change and the CLI compatibility, indeed that would mean one would have to provide a TryInto<Enum> generic there and an implementation to convert from &str to Enum fallibly. With that, the CLI should work again, and user-code would still work as well.

Thanks again for your great work here, it's awesome to see this improved.

[OMGeeky]

I already implemented the TryInto for &str but I'm struggling with changing the generating code in the CLI where I have to use it.
One problem I encountered is that not every enum has a default value. I might have an idea how to get around some of the problems, but I don't really fully get others.

[Byron]

And I thought with the API providing TryInto<Enum> that the CLI code wouldn't have to change at all.

One problem I encountered is that not every enum has a default value.

That's interesting, as I don't even know how this works in the existing code, or if it relies on a default value at all. Maybe the implementation on main just makes something up or has some heuristic?

[OMGeeky]

In this case the value provided was either empty or invalid and I'm not sure what to do in this case.
Should we just ignore this value and move on and see if it throws an error when executing the call?
Maybe output a warning?

[Byron]

If it's possible to make the call anyway, the CLI could probably try it and maybe even emit a warning like you suggested.
Admittedly I don't fully understand this yet, but trying to be lenient for the CLI seems like the right choice here.

[c-git]

@OMGeeky do you want help with this?

[OMGeeky]

@OMGeeky do you want help with this?

Honestly I have not done anything here in a while now. I've hit a dead end and I didn't really like my workflow with mako etc. so it's pretty far but incomplete.
I did however want to understand how everything worked better and started looking into generating rust code like this from within rust and I have been getting pretty far with it by now, so maybe I'm a bit more experienced.

So if you wanna help completing this I'm all for it, maybe we can get this finished.

[c-git]

Sure if you want to drive it to completion, I'm hoping to have some time coming up in a few weeks and this feels like a good place to spend some of that. Or we could wait a while and see how Google's effort shapes up. Either way I think it's a good learning experience for me to help with completing this so either way I don't mind driving it to completion if you want to. I've never worked with generated code I didn't generate myself (amateur hour lol). It was to generate latex from python code.

[c-git]

Hi @OMGeeky I've been following Google's development over the last few days and it seems like they have at least one person on this full time. So I think maybe better we just wait. Thank you for the work you've done so far. I think anything we do on this would just be "for fun". So probably better just to keep the existing functionality working until Google is done.