Kivy Garden and the Ecosystem

The Kivy Garden is the community's package index for Kivy - a registry of reusable widgets, tools, and extensions, installed with a single command into a .kivy directory that Kivy discovers at import time. Around it is the wider ecosystem: the official extras (the Kivy language, the design tools), the adjacent Python libraries a Kivy app commonly uses (the ones covered in the companion tutorials), and the community patterns that fill the gaps the core toolkit leaves. This chapter covers the Garden itself - what it is, how to install and use a package - and maps the ecosystem so you know what to reach for when the core is not enough.

The Garden: Install and Use

# the garden tool, installed with Kivy
pip install kivy-garden

# install a garden package into the project's .kivy directory
garden install button

# the packages land in .kivy/garden/<package>/
# and are importable by their garden name:

# a garden package is imported by its module path,
# exactly like any other Python package:
from garden.button import GardenButton   # example package

# the .kivy directory is auto-discovered:
# Kivy adds it to the import path, so `import garden.xxx` works
# once the package is installed - no sys.path fiddling

The model: garden install <name> fetches the package into .kivy/garden/<name>, and Kivy's startup adds that directory to the import path, so the package is importable by its module name with no installation into site-packages. This is deliberately lightweight - a garden package is a directory of Python (and KV) files, versioned in the project's .kivy so it is part of the app's source tree, not a global dependency. The practical shape of a garden package is almost always a widget (a styled button, a chart, a picker, a virtualized list) that the core toolkit does not ship, and using one is the same as using a custom widget you wrote - import the class, put it in the KV or build it in Python. The discipline is the same as any dependency: pin the package (it is in the tree, so it is versioned with the app), read its source (it is a directory of files, not a wheel), and prefer a well-used package for a core capability over a hand-rolled one.

The Official Extensions and Tools

KivyMD - a Material Design widget theme for Kivy; the standard way to get a Material-styled UI without building every widget's style by hand. It layers over the core widgets, so the app code is unchanged and the appearance is the Material set.
Kivy design and the @ template system - the KV template mechanism (the kv-language chapter) is the official reuse tool, and the design guidance in the docs is the reference for the look-and-feel conventions.
Kivy's core providers - the core layer (window, text, image, audio, video, storage) is the extension point for the OS capabilities, and a provider is how a new backend (a text engine, an image format) plugs in without changing the app code.

The official layer is small and stable: KivyMD for the Material look, the KV templates for in-app reuse, and the core providers for the platform capabilities. The pattern in all three is the same as the core - a declarative or interface-based extension point that the app code uses without knowing the implementation. For a production Kivy app, KivyMD is the usual first addition (the Material widgets cover the common UI shapes with a consistent style), and the core providers are where you go when a capability (a font engine, an image codec) is missing on a target platform.

The Adjacent Python Ecosystem

A Kivy app is a Python app, and the libraries the companion tutorials cover are the natural companions: requests for the networking chapter's HTTP, the json standard library for the storage chapter's data, sqlite3 (or Peewee, for a structured case) when the JSON store outgrows its format, Pillow for image processing on the assets, and numpy for any data the app computes. The integration is plain Python - the Kivy UI is the view, and these libraries are the data and the logic behind it, with the threading chapter's pattern (work out on a thread, result back on the Clock) as the seam. The rule that keeps it clean is the one from the data-driven chapter: the UI is a view over a data layer, and the data layer is where the adjacent libraries live - the requests call in the store, the sqlite3 query in the repository, the Pillow transform on the asset - so the widgets never see the library and the libraries never see the widgets.

The Community Patterns That Fill the Gaps

A virtualized list - the data-driven chapter's recycle-the-widgets pattern, for lists too long to build in full; the standard community solution to the long-list performance rule.
A settings screen - a Screen backed by the storage chapter's store, with the inputs bound to the store's properties; the pattern for any preference UI.
A theming layer - a central palette (a module of color constants) that the KV rules reference, so the app's colors change in one place; the KivyMD alternative is the themed version.
A test harness - a headless run (the software GL backend, the installation chapter's env vars) that starts the app, drives a few events, and exits; the standard smoke test for a Kivy build.

These are the shapes the core does not package and every app ends up building: the virtualized list, the settings screen, the theming module, the headless test. The Garden sometimes has a package for them, and the community patterns are the reference for the hand-rolled version. The ecosystem, then, is three layers - the official (KivyMD, the providers), the Garden (community widgets), and the adjacent Python libraries (the data and logic) - and the app's job is to know which layer a need belongs in, and to keep the seam (the data layer, the threading handoff) clean between them.

Summary

The Kivy Garden is the community package index: garden install <name> puts the package in the project's .kivy directory, which Kivy adds to the import path, so a garden widget is imported and used like any custom class - lightweight, versioned in the tree, no global install. The official layer is KivyMD for the Material look, the KV template system for in-app reuse, and the core providers for the platform capabilities. The adjacent Python ecosystem - requests, json/sqlite3/Peewee, Pillow, numpy - is the data and logic behind the UI, integrated through the threading handoff and kept out of the widgets by the "the UI is a view over the data layer" rule. The community patterns (the virtualized list, the settings screen, the theming module, the headless test) fill the gaps the core leaves. The skill is knowing which layer a need belongs in - official, Garden, or adjacent library - and keeping the seams clean, which is what turns the core toolkit into a full app platform.