Extract ExecuTorchDemo into a dedicated pytorch-labs/executorch-examples repo

[mergennachin]

Currently, there are CV apps inside executorch/examples/demo-apps folder. Specifically:

• https://github.com/pytorch/executorch/tree/main/examples/demo-apps/android/ExecuTorchDemo
• https://github.com/pytorch/executorch/tree/main/examples/demo-apps/apple_ios/ExecuTorchDemo

What are your thoughts on extracting to a separate repo, say, pytorch-labs/executorch-examples, and removing from executorch/examples altogether. Similar to https://github.com/google-ai-edge/litert-samples and https://github.com/ml-explore/mlx-examples

Pros:

• We can build more dedicated showcase apps in this repo (e.g., NLP, CV, LLM, etc) moving forward.
• Showcases an actual out-of-repo app building experience that uses ExecuTorch as a dependency (as opposed to in-tree demo).

Cons:

• Need to update ET version as a dependency and each update may introduce API changes. However, since now we're in beta, it should be fine. If we're changing our APIs, then something's wrong.

[larryliu0820]

I think this is a good idea. I can touch a bit on the pros:

• Simplifies the build system for examples, avoid 2-step CMake build processes (one for executorch one for demo). Existing issue: Move examples + tests to single-step CMake build #8274
• Works well with our existing tokenizers repo: https://github.com/pytorch-labs/tokenizers - ET doesn't have to depend on tokenizers or other LLM related python libs anymore, making the dependency cleaner

[swolchok]

you're going to have to adjust the habit our build files have of simply fiddling with include directories to take advantage of the fact that they live in the ExecuTorch repo rather than introducing a proper CMake dependency on ExecuTorch. I think this is a good thing to fix anyway, though.

[GregoryComer]

I don't have any strong opinion on this, personally. It seems reasonable and can maybe help make the build clearer to users, so that's good. My only concern is discoverability, but hopefully documentation can bridge that gap.

[mergennachin]

My only concern is discoverability, but hopefully documentation can bridge that gap.

Yeah, we can point to this repo in our main documentation.

For example:

"Here's how iOS app is built. Here's what the API looks like. For concrete examples, take a look at this executorch-examples repo"

[dbort]

I think this is a good change.

• It reduces the size and complexity of the core repo.
• The examples will look more like a real user's situation: living in a repo that includes the ET repo as a submodule, or using a prebuilt artifact without submodule-ing the ET repo at all.
• Having a separate repo of client code will be another check on our API BC policy. If someone writes a PR that would require an atomic change across core ET and the examples repo, that PR is likely to violate our BC policy. The example repo is a proxy for real user code, and we can't atomically change their code either.