Working with Hugging Face (HF) can be incredibly rewarding, but like any platform, it comes with its own set of constraints and limitations that can catch developers off guard. Here are some common friction points I encountered which you are better off knowing beforehand to make better decisions with regard to your engineering practices.
- Gradio apps work well in public spaces, but when you make your space private it's UI breaks real bad. For more on this, check out my earlier post titled, "Gradio App Breaks in Hugging Face's Private Spaces".
- HF discourages the use of .env file for externalizing your configurations and recommends the use of its settings tab in the console to set your environment variables. At least as of now, this is only a recommendation and I see it working for my demo apps. This might change in future, and it may reject the commit having .env file as unsafe, in future. This recommendation is understandable and recommendable for production grade apps. With hobby apps that I develop and deploy, I am conscious of my reason to break the rule and so should you in your play.
- HF repositories, which are based on Git, do indeed have policies regarding the types of files that can be directly committed. It is strict about rejecting commits having non-code artefacts like images, pre-trained models or other binary files, no matter how small you think it is.
- In HF you either make your space entirely public or entirely private, from its settings tab. There isn't a way you can make the code private and the app public. Apparently, this is the most sought after feature in HF Spaces.
- HF Spaces, once created with a specific SDK (like Gradio, Streamlit, or Shiny) or as a Docker-based Space, cannot be directly converted or changed to a different deployment mode after creation. The Readme.md file section has meta-data section that shows the option you have chosen at the time of creation of the space. I assumed that changing this value would change the deployment mode; and I was wrong with this assumption. You can give it a try and it will have no effect. So in summary, this means:
- A Docker Space cannot be converted to a Gradio Space.
- An SDK-based Space (e.g., Gradio) cannot be converted to a Docker Space.
- HF Spaces are designed to run from the main branch of their associated Git repository by default. There is no direct configuration option within the Space settings to specify a different branch for the live application. I personally wish this feature exists to make my life easier. However, workarounds exist to achieve a similar outcome which is as below that you can adopt for your production environment, if you so desire:
- Create separate spaces for different branches of a repository.
- Create multiple Hugging Face Spaces.
- Add each Space as a separate remote in your local repository.
- Push specific branches to their corresponding Space remotes. For instance, push your development branch to a "dev" Space and your main branch to a "production" Space.
- Alternative to the above steps, if you are using GitHub as your origin repository, you may use Github Actions for branch-specific deployment.