Package WebXR client resources for fully offline local hosting

[sgrizan-nv]

Problem

Isaac Teleop's local WebXR client serving workflows still require downloading the client resources from GitHub Pages before they can be served locally.

That creates an unnecessary network dependency for workflows that are intended to operate locally, particularly in:

• air-gapped environments
• corporate networks with restricted Internet access
• lab environments without reliable external connectivity
• deployments where GitHub Pages is blocked or unreliable

This affects local serving workflows such as:

python -m isaacteleop.cloudxr --accept-eula --setup-oob --usb-local

and:

python -m isaacteleop.cloudxr --accept-eula --local-host

Today, the web resources can be downloaded/cached and then served locally, but the initial download still requires network access.

Desired behavior

Package the WebXR / CloudXR.js client resources together with Isaac Teleop so that local hosting does not require any runtime download.

For example, the resources could be shipped as:

• normal Python package data, or
• an optional wheel/package extra if the additional package size is significant

Once Isaac Teleop is installed, both USB-local and non-USB local-host workflows should be able to serve the web client without Internet access.

Conceptually:

Isaac Teleop installation
        |
        +-- packaged WebXR / CloudXR.js client assets
                         |
                         +-- --usb-local
                         |
                         +-- --local-host

rather than:

Isaac Teleop
    |
    +-- download client from GitHub Pages
                    |
                    +-- cache locally
                    |
                    +-- serve locally

Why this would help

Packaging the web resources with Isaac Teleop would:

• make local-hosting workflows genuinely offline-capable
• remove GitHub Pages availability from the runtime dependency chain
• make setup more deterministic
• improve support for restricted and air-gapped deployments
• ensure the locally served client is versioned together with the Isaac Teleop release
• reduce ambiguity around which client version is compatible with a given Isaac Teleop installation

Suggested acceptance criteria

• The web client assets required for local hosting are distributed with Isaac Teleop.
• --usb-local can serve the client on a machine with no Internet access and no previously cached client.
• --local-host can serve the client on a machine with no Internet access and no previously cached client.
• The packaged client resources are versioned together with the Isaac Teleop release.
• A fresh Isaac Teleop installation can exercise the local-serving paths without contacting GitHub Pages.
• Existing hosted/online client workflows continue to work as they do today.
• If retaining a download/update path is useful, it is optional rather than required for local serving.

Packaging considerations

A few implementation options may be worth considering:

1. Package data in the main Isaac Teleop wheel

   Simple user experience, although it increases the base wheel size.

2. Optional package extra

   For example, a local/offline or CloudXR web-client extra containing the static assets.

3. Separate versioned asset package

   A small companion Python package containing the web client resources, pinned to a compatible Isaac Teleop version.

Whichever approach is used, the important property is that the local-serving commands resolve the web resources from the installed package rather than requiring an initial GitHub Pages download.