Push to Hub Design

It would be nice to discuss a bit the push to hub design of the library.

IMO we have two different use cases for push_to_hub.

1. The complement of from_pretrained(...). Every model, scheduler, and diffusion pipeline should eventually have a push_to_hub(...) method that allows one to push the class to the Hub. IMO this method can mirror 1-to-1 the API we have for Transformers: https://huggingface.co/docs/transformers/v4.21.2/en/main_classes/model#transformers.PreTrainedModel.push_to_hub maybe with the repo_url argument. This function has a very clear purpose and often doesn’t need customization. It’s as simple as “push the object that you’re currently holding to the Hub exactly like as is”. We don’t have this functionality yet, but it would be cool to integrate it soon. There IMO we can abstract away most of the logic from the user

2. Push to Hub in the example scripts. Our example scripts should foremost be “easy-to-understand” and “easy-to-tweak” and the ability to push to the Hub should be included in this philosophy. There are a lot of different use cases how someone might want to push to the Hub during training (e.g. only some parts of the pipeline, only when a condition is met, etc…) => here let’s give the user maximum flexibility by just showing the fundamental blocks that are needed from huggingface_hub - just like it’s done in: https://github.com/huggingface/transformers/blob/f719c0377f7f97c4bf9b6b54de209f4aad0aef4b/examples/pytorch/text-classification/run_glue_no_trainer.py#L242 . I think this is even more important for diffusion models because they have many more components

What do you think @patil-suraj @pcuenca @anton-l ?

[Wauplin]

Hey there 👋 @osanseviero pointed this issue to me (as well as https://github.com/huggingface/diffusers/issues/81). In general, I’d be glad to help in integrating more huggingface_hub in diffusers when needed. This issue seems a very good start.

To come back to @patrickvonplaten message:

1. That’s definitely what push_to_hub is meant to be. Since v0.9, hfh has a new “http-based push-to-hub mixin” called ModelHubMixin. This is not well documented yet but the idea is to inherit your model/scheduler/pipeline classes from ModelHubMixin and implement the private _from_pretrained() and _save_pretrained() methods. By doing this, you automatically have a class with public methods from_pretrained, save_pretrained and push_to_hub. This leverages the http API which means no need to clone a repo locally. => I would be very up to help on this integration. This would be a good exercise for me on a “real” integration and a good occasion to update the hfh documentation.

2. For the record, http-based methods cannot be run in the background at the moment. There is no blocking=False argument implemented (doesn’t mean it will never be 😃 ). So we can either push to use the Repository object or work on making the http-based helpers usable in a training environment. I’m not sure to be the right person in this context (documenting push during training possibilities) but let me know if you have hfh-related questions here 😃

[anton-l]

1. Something to consider here is also where we should put the model card generator (with training hypermarameters, per-epoch metric logs, etc.). But otherwise I’m very eager to remove the git-related complexity from the examples, especially with the upcoming git-less push_to_hub in huggingface_hub==1.0