Move app-only dependencies to an optional extra (aiohttp, click, prompt_toolkit, prettytable, humanize, tomli)

[james-shull-at-oura]

Summary

Six runtime dependencies are only imported by the bundled apps and tools, never by the
library itself. Installing bumble to use it as a Bluetooth stack currently also installs a
web server, a CLI framework, and a terminal UI toolkit.

Would you consider moving them behind an optional extra, e.g. bumble[apps]?

Detail

Checked against 0.0.233, counting files that import each module under bumble/ versus
apps/ + tools/:

Dependency	core	apps/tools
click	0	24
aiohttp	0	2
prompt_toolkit	0	2
prettytable	0	1
humanize	0	1
tomli	0	1

aiohttp is the one that prompted this. It is used only by apps/speaker/speaker.py and
apps/lea_unicast/app.py, both for aiohttp.web to serve a browser UI. We consume bumble
purely as a library (bumble.device, bumble.hci, bumble.gatt, bumble.transport, …) and
never import bumble.apps, but we still had to resolve a high-severity aiohttp advisory
(GHSA-cq5v-8q36-5273) in our lockfile because it is a transitive pin. Dependency scanners look
at the lockfile, not the call graph.

Why it matters

• Supply-chain surface: a BLE library pulls in an HTTP server and its dependency tree.
• Security churn: advisories in app-only packages become work for every downstream consumer.
• Install weight for embedded/CI environments that only need the stack.

Suggested shape

The project already uses optional dependencies for android and auracast, so this would
follow the existing pattern:

[project.optional-dependencies]
apps = [
    "aiohttp ~= 3.8; platform_system!='Emscripten'",
    "click >= 8.1.3; platform_system!='Emscripten'",
    "prompt_toolkit >= 3.0.16; platform_system!='Emscripten'",
    "prettytable >= 3.6.0; platform_system!='Emscripten'",
    "humanize >= 4.6.0; platform_system!='Emscripten'",
    "tomli ~= 2.2.1; platform_system!='Emscripten' and python_version<'3.11'",
]
all = ["bumble[android]", "bumble[auracast]", "bumble[apps]"]
pip install bumble gets the stack; pip install bumble[apps] gets the demos and CLI tools.

The obvious objection
[project.scripts] declares ~20 console scripts pointing at bumble.apps.*, so a bare
install would still create the entry points but they would fail on import. Options, roughly in
order of effort:

1. Document it, and let the ImportError speak for itself.
2. Have the app entry points catch ImportError and print "install bumble[apps] to use this tool".
3. Move the scripts under the extra too, if the packaging tooling allows it cleanly.

Happy to send a PR for whichever shape you prefer, if this is something you would take.

[zxzxwu]

This used to be an option for #897, but it's finally removed because:

1. I am not sure how many users are using the applications. If they are popular, using a option group could be annoying.
2. I would like to keep option dependency groups as few a possible.

An option is that we can try to remove the usage to these deps. For example, using built-in http module for static file handling.

[zxzxwu]

aiohttp, humanize, prettytable are removed in #968.

[barbibulle]

I think that moving apps to its own dependency group would make sense, as long as we handled the installs cleanly. Either let the scripts be installed always, and catch the import error (option 2 above) or option 3 if that's possible.
More generally, we have the same issue with transports, where some transports (like usb) have non-trivial dependencies (libusb in the case of the usb transport). So far, we've only "bumped" android as a separate group, but it might make sense to also split out other "heavy" transports. I might take a crack at proposing a completely modular version of pyproject.toml to see what it would look like.