Refactor analytics to not use api.gradio.app

[freddyaboulton]

Description

🎯 PRs Should Target Issues

Before your create a PR, please check to see if there is an existing issue for this change. If not, please create an issue before you create this PR, unless the fix is very small.

Not adhering to this guideline will result in the PR being closed.

Tests

1. PRs will only be merged if tests pass on CI. To run the tests locally, please set up your Gradio environment locally and run the tests: bash scripts/run_all_tests.sh

2. You may need to run the linters: bash scripts/format_backend.sh and bash scripts/format_frontend.sh

[gradio-pr-bot]

🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	ready!	Website preview
:unicorn:	Changes	detected!	Details

---

Install Gradio from this PR

pip install https://gradio-builds.s3.amazonaws.com/522fa68788345948972f96128f3cc6f02a07064a/gradio-4.28.3-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@522fa68788345948972f96128f3cc6f02a07064a#subdirectory=client/python"

[gradio-pr-bot]

🦄 change detected

This Pull Request includes changes to the following packages.

Package	Version
gradio	patch

• [ ] Maintainers can select this checkbox to manually select packages to update.

With the following changelog entry.

Refactor analytics to not use api.gradio.app

Maintainers or the PR author can modify the PR title to modify this entry.

#### Something isn't right?

- Maintainers can change the version label to modify the version bump. - If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can [update the changelog file directly](https://github.com/gradio-app/gradio/edit/analytics-local/.changeset/gentle-berries-fetch.md).

[abidlabs]

Instead of using (internal) _send_telemetry_in_thread, why not use send_telemetry? That way we can avoid spinning up our own thread for each analytics request and instead use the single-thread approach that is baked into huggingface_hub (since Lite doesn't support threads, I guess we'd still need to use _send_telemetry_in_thread in that case)

cc @Wauplin

[freddyaboulton]

@abidlabs _send_telemetry_in_thread does not actually launch a new thread as far as I can tell, it just sends the request to HF hub. In contrast, send_telemetry will place data in a queue and then start a new thread to pull data off that queue and send to the hub. I think we still need to run the analytics in a separate thread so that the "get ip address" operation does not block, so I think _send_telemetry_in_thread is better to not have an additional background thread running.

[abidlabs]

@freddyaboulton yes you're right, the _send_telemetry_in_thread, but create a thread ourselves, e.g. when we do:

threading.Thread(
            target=_do_normal_analytics_request,

it seems like it'd be better to use the documented public method if possible?

[abidlabs]

Nvm @freddyaboulton you are right we will need to spin our own thread to get the IP so let's stick with _send_telemetry_in_thread. @Wauplin is that a safe choice or is there a better option you'd suggest?

[Wauplin]

we will need to spin our own thread to get the IP so let's stick with _send_telemetry_in_thread. @Wauplin is that a safe choice or is there a better option you'd suggest?

It's a reasonably safe choice yes. Don't see a better option that does not involve re-implementing the request. Could you add a comment in huggingface_hub's _send_telemetry_in_thread to reference to gradio-lite so that we don't forget? Little chance we change this internal method anytime soon but better safe that sorry :)

[freddyaboulton]

Yes will do @Wauplin thanks!

[freddyaboulton]

Ok this is ready for review now

[freddyaboulton]

Yes analytics are going through! Thank you for the review!