This document describes the packaging configuration for the Feast Python SDK, including dependency management, build process, and distribution artifacts. For information about the overall build system orchestration, see Build System and Dependency Management. For details on release versioning and publishing, see Release Process and Versioning.
The Feast Python SDK is packaged as a standard Python wheel distributed via PyPI under the name feast. The packaging configuration uses modern PEP 517/518 standards with pyproject.toml as the primary configuration file. The package supports multiple Python versions (3.10, 3.11, 3.12) and includes over 30 optional feature sets through [project.optional-dependencies], allowing users to install only the dependencies needed for their deployment scenario.
Key Packaging Components:
| Component | Purpose | Primary File |
|---|---|---|
| Package definition | PEP 517/518 metadata and dependencies | pyproject.toml1-236 |
| Dependency locking | Pinned requirements with hashes | sdk/python/requirements/*.txt |
| Build orchestration | Make targets for packaging tasks | Makefile1-858 |
| Build system | setuptools with setuptools_scm | pyproject.toml224-233 |
Sources: pyproject.toml1-236 Makefile1-858
The primary package configuration is defined in pyproject.toml1-236 following modern Python packaging standards. The package uses setuptools_scm for dynamic versioning derived from Git tags.
Package Metadata Structure
Core Package Definition
The [project] section defines the package metadata:
The version is dynamically determined from Git tags using setuptools_scm configuration in the build system section.
Sources: pyproject.toml1-15
The package structure is configured in the [tool.setuptools] section:
This configuration:
sdk/python/ directoryjava, infra, ui, tests).so), protobuf files, and UI build artifactsSources: pyproject.toml235-256
Feast uses a sophisticated dependency management system with a minimal core and extensive optional extras. This allows users to install only what they need for their specific use case.
Core Dependency Categories
Core Dependencies Table
The [project.dependencies] array in pyproject.toml defines 27 core dependencies that are always installed:
| Category | Dependencies | Purpose |
|---|---|---|
| CLI | click, colorama, tabulate | Command-line interface and formatting |
| Config | PyYAML>=5.4.0, toml>=0.10.0, jsonschema | Configuration file parsing |
| Data | pandas>=1.4.3, pyarrow>=21.0.0, numpy>=2.0.0, dask[dataframe] | DataFrame operations |
| Web | fastapi>=0.68.0, uvicorn[standard], gunicorn, uvicorn-worker | Feature server HTTP/gRPC |
| Types | pydantic>=2.10.6, protobuf>=4.24.0, typeguard>=4.0.0 | Schema validation |
| Database | SQLAlchemy[mypy]>1 | Metadata storage ORM |
| Utils | requests, tqdm>=4, tenacity>=7, mmh3, Jinja2>=2, dill~=0.3.0 | HTTP, progress bars, retries, hashing, templating, serialization |
| Monitoring | prometheus_client, psutil | Metrics and system info |
| Tree | bigtree>=0.19.2, pyjwt | Hierarchical feature views, JWT tokens |
Sources: pyproject.toml16-46
The package defines 34 optional extras through [project.optional-dependencies], organized by integration type:
Optional Extras Organization
Extras by Category
The optional dependencies are organized into logical groups in [project.optional-dependencies]:
| Category | Extras | Example Dependencies |
|---|---|---|
| Cloud | gcp, aws, azure, snowflake | google-cloud-bigquery>=2, boto3==1.38.27, azure-storage-blob>=0.37.0, snowflake-connector-python[pandas]>=3.7 |
| Online Stores | redis, postgres, postgres-c, mysql, cassandra, elasticsearch, milvus, hazelcast, singlestore, qdrant | Database-specific Python drivers |
| Offline Stores | spark, trino, duckdb, ibis, mssql, clickhouse, couchbase | pyspark>=4.0.0, trino>=0.305.0, ibis-framework[duckdb]>=10.0.0 |
| File Formats | delta | deltalake<1.0.0 |
| ML/AI | pytorch, rag, image, docling, nlp | torch>=2.7.0, transformers>=4.36.0, datasets>=3.6.0, docling==2.27.0 |
| Infrastructure | k8s, grpcio, opentelemetry, openlineage | kubernetes, grpcio>=1.56.2, prometheus_client, openlineage-python>=1.40.0 |
| Development | ci, dev, docs, dbt | Testing frameworks, linters, type checkers, documentation tools |
| Special | minimal, minimal-sdist-build, setuptools | Production runtime, build dependencies, setuptools compatibility |
Sources: pyproject.toml48-213
Several extras combine multiple feature sets for common deployment scenarios:
minimal: Production feature server deployment
ci: Complete testing environment with all integrations
nlp: Natural language processing with vector search
minimal-sdist-build: Dependencies needed to build from source distribution
Sources: pyproject.toml187-209
Dependencies are locked with exact versions and SHA256 hashes for security and reproducibility. The lock files are generated using uv pip compile and stored in sdk/python/requirements/.
Lock File Structure
Each lock file includes:
uv pip compile command used to generate itExample entry format from py3.10-ci-requirements.txt:
aiohttp==3.13.3 \
--hash=sha256:01ad2529d4b5035578f5081606a465f3b814c542882804e2e8cda61adf5c71bf \
--hash=sha256:042e9e0bcb5fba81886c8b4fbb9a09d6b8a00245fd8d88e4d989c1f96c74164c \
# via
# aiobotocore
# fsspec
The header documents the generation command:
# This file was autogenerated by uv via the following command:
# uv pip compile -p 3.10 --no-strip-extras pyproject.toml --extra ci --generate-hashes --output-file sdk/python/requirements/py3.10-ci-requirements.txt
Sources: sdk/python/requirements/py3.10-ci-requirements.txt1-138 sdk/python/requirements/py3.11-requirements.txt1-2
Lock File Generation Pipeline
Makefile Target
The lock-python-dependencies-all target regenerates all 15 lock files (5 types × 3 Python versions):
The process uses:
Sources: Makefile130-153
The Makefile provides multiple installation targets for different development and deployment scenarios:
Installation Target Flow
Installation Target Summary
| Target | Use Case | Method | Installation Mode |
|---|---|---|---|
install-python-dependencies-dev | Full local development with all test deps | uv pip sync --require-hashes + editable install | Editable with hash verification |
install-python-dependencies-minimal | Production-like local testing | uv pip sync minimal-requirements.txt + editable | Minimal feature set |
install-python-dependencies-ci | GitHub Actions workflows | uv venv + uv pip sync with torch handling | Isolated virtualenv for CI |
Sources: Makefile91-114
The install-python-dependencies-ci target includes platform-specific PyTorch handling to avoid large CUDA dependencies:
This approach:
--extra-index-url to prioritize CPU-only PyTorch wheels on Linux--no-deps to avoid re-resolving locked dependenciesSources: Makefile103-114
The Python SDK build process involves multiple steps, coordinated through Make targets and the PEP 517/518 build system.
Build Pipeline Components
Sources: Makefile53-55 Makefile155-156 Makefile780-781 pyproject.toml224-233
Protobuf Compilation
The compile-protos-python target generates Python code from Protocol Buffer definitions:
The generation script:
.proto files in protos/feast/{core,types,serving,storage}/protoc with --python_out and --mypy_out pluginssdk/python/feast/protos/__init__.py files for package structureThe generated files are included in the wheel via tool.setuptools.package-data in pyproject.toml:
Sources: Makefile155-156 pyproject.toml249-253
Web UI Bundling
The Feast UI (React application) must be built before packaging:
This creates sdk/python/feast/ui/build/ containing the static assets, which are included via:
Sources: Makefile780-781 pyproject.toml254-255
Python Package Building
The package uses the build module (PEP 517 frontend) for creating artifacts:
Build configuration in pyproject.toml:
The build creates:
feast-{version}-py3-none-any.whl — pure Python, no compiled extensionsfeast-{version}.tar.gz — complete source treeWheel naming components:
py3: Compatible with Python 3.xnone: No specific ABI requirements (pure Python)any: Works on any platform (no native code)Sources: pyproject.toml224-233
The [build-system] section declares dependencies needed during the build:
| Dependency | Purpose |
|---|---|
pybindgen==0.22.0 | Generates C bindings for optional Go integration via CFFI |
setuptools>=60,<81 | Build backend implementation |
setuptools_scm>=6.2 | Derives version from Git tags automatically |
sphinx!=4.0.0 | Documentation generation (docstrings) |
wheel>=0.46.2 | Wheel format support |
Version determination happens via setuptools_scm configuration:
This extracts the version from the most recent Git tag matching Feast's format (e.g., v0.40.0, sdk/python/v0.40.0).
Sources: pyproject.toml224-233 pyproject.toml257-258
Feast supports Python 3.10, 3.11, and 3.12, with separate lock files for each version.
Version Detection
Sources: Makefile30-32
The Makefile automatically detects the Python version:
This is used to select the appropriate lock file for installation:
Sources: Makefile30-32 Makefile69-71
Some extras include version-specific dependencies:
Sources: setup.py190-193
This allows different dependency versions or alternatives based on Python version.
The package registers the feast CLI command as a console script in pyproject.toml:
This configuration:
feast executable in the virtualenv's bin/ directory when installedcli() function in the feast.cli.cli module.exe wrapper on WindowsSources: pyproject.toml221-222
The minimal-sdist-build extra includes dependencies for building the package from source distribution in resource-constrained environments:
This extra:
feast[minimal] for runtime dependenciesmilvus-lite (via --no-emit-package in lock file generation) which has large CUDA-related binariesThe corresponding lock files (py3.X-minimal-sdist-requirements.txt) are generated with:
Key build dependencies:
| Dependency | Purpose |
|---|---|
meson, meson-python | Build system for NumPy and scientific Python packages |
Cython>=0.29.34 | Compile Python extensions to C |
pybindgen==0.22.0 | Generate C++ bindings for CFFI/Go integration |
patchelf | Modify ELF binaries for Linux wheel repair |
scikit-build-core | CMake-based build backend |
hatchling, flit_core | Alternative build backends for dependencies |
Sources: pyproject.toml188-209 Makefile142-147
The package includes PyPI classifiers and metadata for discoverability:
The classifiers help PyPI categorize the package and inform users about:
Sources: pyproject.toml1-15 pyproject.toml215-220
Key Takeaways:
Refresh this wiki
This wiki was recently refreshed. Please wait 5 days to refresh again.