Package 'pydeck' does not build as-is via the AIPCC self-service pipeline and requires builder repository onboarding.

Build Failure Summary

Build Failure Analysis: `pydeck 0.9.1`

Root Cause

The build fails with an `AttributeError` in setuptools when processing the `readme` field from `pyproject.toml`:

File ".../setuptools/config/_apply_pyprojecttoml.py", line 187, in _long_description
    file = val.get("file") or ()
           ^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'

The `readme` field in pydeck's `[project]` table in `pyproject.toml` is set to `None` (or is present but empty). When setuptools attempts to interpret it as a dictionary (to look up a `"file"` key), it crashes because the value is `NoneType`.

Context

The log also shows a series of `_MissingDynamic` warnings for `readme`, `license`, `authors`, `keywords`, `classifiers`, `dependencies`, and `optional-dependencies`. These indicate that pydeck defines most of its metadata in `setup.py`/`setup.cfg` rather than in `pyproject.toml`, but the `[project]` table exists in `pyproject.toml` without listing those fields as `dynamic`. The newer version of setuptools used in the build environment enforces the PEP 621 specification more strictly than what pydeck 0.9.1 was written against.

The fatal error is specifically on `readme` — unlike the other fields that merely produce warnings, the `readme` field triggers a code path that dereferences `None` and crashes.

Fix

Patch `pyproject.toml` in the pydeck 0.9.1 source before building. Two options:

1. Set `readme` to a valid value in the `[project]` table:
```toml
[project]
readme = "README.md"
```

2. Remove `readme` from `[project]` and declare it as dynamic so setuptools picks it up from `setup.py`:
```toml
[project]
dynamic = ["readme", "version", "license", "authors", "keywords", "classifiers", "dependencies", "optional-dependencies"]
```
(Adding the other warned fields to `dynamic` as well would eliminate the warnings, though only `readme` is causing the crash.)

Either approach ensures that setuptools receives a valid value instead of `None` when processing the readme metadata. A minimal patch targeting only the `readme` field is sufficient to unblock the build.

Packaging Analysis Summary

Here is the executive summary formatted as a JIRA comment in JIRA wiki markup:

Executive Summary: pydeck Packaging Analysis

pydeck is a Simple complexity pure-Python package (complexity score: 1/10) that provides Python bindings for deck.gl map visualizations. It requires no native compilation — the package is 100% Python code with pre-built JavaScript assets bundled in the sdist and wheel. The resulting wheel is tagged py2.py3-none-any, meaning it is platform-independent and works across all target architectures (x86_64, aarch64, ppc64le, s390x) without modification. The license is Apache-2.0 (Linux Foundation project), which is fully compliant with Red Hat redistribution requirements. Runtime dependencies are minimal: jinja2 and numpy, both BSD-3-Clause licensed.

The sole build blocker is a misconfigured setup_requires in setup.py that declares jupyter>=1.0.0 as a setup-time dependency. In PEP 517 isolated build environments, this causes a cascading failure as pip attempts to install the entire Jupyter stack (including notebook and jupyterlab) before the build even starts. This is a known issue with a proven workaround: remove pyproject.toml before building, which forces pip to skip build isolation. This is the same approach used in production by the conda-forge feedstock.

The recommended build strategy is straightforward:

tar xzf pydeck-0.9.1.tar.gz {{ANALYSIS_SUMMARY_CONTENT}}{{ANALYSIS_SUMMARY_CONTENT}} cd pydeck-0.9.1
rm pyproject.toml
pip wheel . --no-deps --no-build-isolation -w dist/

This produces a ~6.7 MB noarch wheel with no compilation step. No special environment variables, system libraries, or external toolchains are required. As a fallback, the pre-built wheel from PyPI is functionally identical since no compiled code is involved.

Key context: pydeck is a transitive dependency in the chain streamlit-option-menu → streamlit → pydeck. The current PyPI release (0.9.1, released 2024-05-10) ships with an older JavaScript frontend (issue #9435), but this is a runtime cosmetic concern and does not affect the build or packaging process. No upstream engagement is needed to unblock onboarding — the pyproject.toml removal workaround fully resolves the only build issue.