Add initial version of deploy_on_spaces

[davidberenstein1957]

Pull Request Template

Add default deployment options for Hugging Face spaces through the Hugging Face hub api.

Closes #5108

• Added DeploymentMixin class within _deploy.py within _helpers directory
• Added huggingface_hub as core dependency under the assumption it is lightweight and we will soon use it for telemetry too.

TODO:

• docs
• tests
• evaluation w.r.t. oauth deployment for using argilla vs argilla-space-with-oauth @frascuchon do you know what the difference is when using these templates?

Usage:

import argilla as rg

client = rg.Argilla.deploy_on_spaces(
    repo_id="my-org/my-space",
    token="hf_ABC123",
    space_storage="10GB",
    space_hardware="gpu",
    private=True,
    admin_username="admin",
    admin_password="password123",
    owner_username="owner",
    owner_password="ownerpass",
    annotator_username="annotator",
    annotator_password="annotatorpass",
    argilla_workspace="workspace",
    oauth_huggingface_client_id="client_id",
    oauth_huggingface_client_secret="client_secret"
)

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested

Checklist

• I added relevant documentation
• follows the style guidelines of this project
• I did a self-review of my code
• I made corresponding changes to the documentation
• I confirm My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have added relevant notes to the CHANGELOG.md file (See https://keepachangelog.com/)

[burtenshaw]

This is useful functionality, but I'm not sure that it needs to be in the sdk because it will introduce maintenance challenges. As you mention in the comment: oauth, testing.

Instead, could this be an example of the first extension?

[Josephrp]

it would fit quite nicely in a "huggingface spaces sdk" , which is something to look forward to

[davidberenstein1957]

@burtenshaw not sure why the OAuth is an issue. I thought of adding it as an extra but I think the value of the integration also lies in the fact that it works on the fly as an entry point so I would then propose showing it on import or function execution instead of mentioning it everywhere through the docs. WDYT?

[davidberenstein1957]

@frascuchon argilla-space vs argilla-space-with-oauth do you know what the difference is between these Hugging Face spaces templates?

[burtenshaw]

@burtenshaw not sure why the OAuth is an issue. I thought of adding it as an extra but I think the value of the integration also lies in the fact that it works on the fly as an entry point so I would then propose showing it on import or function execution instead of mentioning it everywhere through the docs. WDYT?

Sorry. I didn't explain this point properly. I meant that oauth, and other challenges, could increase the complexity of the module and so might be better placed in another package.

That said, I'm not 100% against this inclusion in the SDK. But I do think it's a significant change that we should find the best place for. My main concern is that we end up with too much utilities code in the SDK that's difficult to maintain on a daily basis. And doesn't offer much value to the user beyond a well documented Spaces deployment guide.

If we do include this in the SDK, rather than an extension, I'd say that we should interface it consistently with the Argilla class.

But, I'd like to also here from @frascuchon and @dvsrepo .

[burtenshaw]

it would fit quite nicely in a "huggingface spaces sdk" , which is something to look forward to

@Josephrp what's the latest on this?
@davidberenstein1957 should we follow this up?

[dvsrepo]

@frascuchon argilla-space vs argilla-space-with-oauth do you know what the difference is between these Hugging Face spaces templates?

The official is this one: https://huggingface.co/spaces/argilla/argilla-template-space (the one that is used by the New Space UI HF flow too).

The other one is an unofficial one I created to be able to launch oauth spaces more easily

[davidberenstein1957]

@dvsrepo @burtenshaw and I decided to go forward with this. @frascuchon do you have any specific opinion about the PR and location of the Mixin within the package?

[nataliaElv]

@davidberenstein1957 Is this ready to go into 2.1.0 version or should I move it to 2.2.0?