Refactor metadata

[isabelizimm]

• Sets package name in each handler, which allows create_meta to live solely in BaseHandler, rather than in each handler. This also removed the need for describe in each handler.
• On pinning, creates vetiver_meta inside the metadata, which is not loaded on VetiverModel creation, fixing the bug where user data is duplicated. On the R side, a list is pinned with metadata, rather than the model being pinned, and loading the metadata.
• Records package versions of required_pkgs on VetiverModel creation
• Adds more tests for metadata

[machow]

I left some questions about the .pkg attribute. Let's spend some of our pairing time today going over how metadata is being created <-> stored!

[machow]

One last high-level thought: I just realized you could stash the model inside a dictionary (like R vetiver does). joblib should be able to serialize / deserialize a dictionary where one field is a model. (But also this way of handling the metadata seems totally reasonable!).

[isabelizimm]

One last high-level thought: I just realized you could stash the model inside a dictionary (like R vetiver does). joblib should be able to serialize / deserialize a dictionary where one field is a model. (But also this way of handling the metadata seems totally reasonable!).

This would make sense if I wanted to mimic R and move ptype and required_pkgs into the dictionary as well (effectively removing the need for vetiver_meta inside a pin). Although, I could pin just a dictionary with just the model, nothing else (unclear what value that would add?). Downfalls of this is that you would have to load the entire joblib file to be able to see the ptype and required_pkgs, which might be useful to be able to see without loading this file.

rstudio/vetiver-r#116 is related to this.

[machow]

Thanks -- that's helpful context around why you have done it this way!

[machow]

This is shaping up--thanks for being patient with all the metadata comments 😵‍💫. I left some note along two themes:

• can we move any metadata logic (including dealing with metadata dictionaries) into VetiverMeta? Can VetiverModel ensure its metadata attr is a VetiverMeta (and add a type hint)?
• the pkg logic right now is a bit tricky, since a parent class expects it, but a child class might define it as a class attribute. It might be helpful to move this piece into a separate PR to get the metadata stuff in.

[isabelizimm]

to handle the pkg weirdness, the pkg attribute was removed. if there is a pip name, it will be handled as expected, otherwise it will set to None.