Allow for HF org with different name from code platform org#110
Conversation
324f8b8 to
093bd05
Compare
| ORGANIZATION_NAME: imageomics # GitHub/Hugging Face organization name (lowercase for API calls) | ||
| ORG_NAME: Imageomics # Display name for GitHub organization (can differ from API name) | ||
| ORGANIZATION_NAME: imageomics # Codebase platform organization name (lowercase for API calls) | ||
| HF_ORGANIZATION_NAME: imageomics # Hugging Face organization name (lowercase for API calls) |
There was a problem hiding this comment.
Since HF_ORGANIZATION_NAME is now required, have we confirmed this won't break existing deployments using older config files that only define ORGANIZATION_NAME?
There was a problem hiding this comment.
I can build in backwards compatibility by using ORGANIZATION_NAME as a fallback, but I've also added validation for the config earlier and am fixing some of the other fallbacks, so I'm not sure we'd want to keep pulling that forward.
beanbean9339
left a comment
There was a problem hiding this comment.
I think overall it looks good to go. Just a few things I noticed while reviewing, but none of them would block functionality, more so things to consider:
- The lowercase validation is helpful, though it may be worth considering validation against allowed organization name characters in the future rather than only checking case.
- CONFIG_PATH
andparsedConfiginvite.config.jscould potentially beconstinstead oflet` since they don't appear to be reassigned.
Other than that, the implementation, tests, and documentation updates all look good to me
no need to do more if not defined
beanbean9339
left a comment
There was a problem hiding this comment.
Overall looks good to me. Nice work separating the HF org handling and tightening up validation and tests. Looks good to merge 👍
As I was setting up a test config for a Codeberg organization, the challenge of a Hugging Face org having a different name than the code platform org became glaringly obvious. This PR fixes that by adding a
HF_ORGANIZATION_NAMEparameter. As discussed in #93, adding a different data or model platform would be a much bigger project requiring community motivated use-case(s), and having HF optional would be similar. Thus, this is a simple parameter addition; the app also requires it to be filled.It also adds a config validation check on Vite start which includes a check that the organization name variables are follow platform format specifications. It is better, especially in a dev/setup context, to have the app fail with an informative message instead of appearing to work but with only online console errors. Example local console output with invalid HF org name and unsupported platform passed:
The config path is defined from a variable in the message.