# py3-pip 25.0.1 — el instalador de paquetes de Python, como MÓDULO IMPORTABLE del sistema.
#
# ══ POR QUÉ EXISTE, Y NO ES PARA INSTALAR NADA DE INTERNET ══════════════════════════════════════
# Esta distro no baja paquetes de PyPI: el sandbox de `takana build` no tiene red, y eso es
# deliberado. `pip` entra por una razón distinta y precisa: **hay builds que preguntan si `pip`
# existe y cambian de camino según la respuesta.**
#
# El caso medido es `qemu` (2026-10-20). Su `configure` crea un entorno virtual y decide así
# (`python/scripts/mkvenv.py:244-251`):
#
#     if system_site_packages and not need_ensurepip():
#         kwargs["with_pip"] = False        # ← usa el pip y setuptools DEL SISTEMA
#     else:
#         check_ensurepip()                 # ← crea su propio pip y acaba yendo al índice
#
# y `need_ensurepip()` es literalmente `find_spec("setuptools") and find_spec("pip")`. Con
# `py3-setuptools` puesto pero sin `pip` importable, qemu tomaba la segunda rama y moría así:
#
#     ERROR: Could not find a version that satisfies the requirement setuptools>=44.1.1
#            (from versions: none)
#
# ⚠ Y el detalle que lo hace inevitable: **en Python 3.12 `ensurepip` ya NO incluye setuptools**,
# sólo pip. Así que la rama del `ensurepip` nunca puede completarse sin red, por mucho que
# setuptools esté instalado en el sistema — el venv que crea no lo hereda.
#
# ⇒ Con `pip` importable, qemu toma la PRIMERA rama, no crea pip propio, y resuelve su wheel
# vendorizado (`python/wheels/qemu_qmp-0.0.6-py3-none-any.whl`) con el pip del sistema. Sin red.
#
# ══ LA VERSIÓN NO ES «LA ÚLTIMA» A PROPÓSITO ═══════════════════════════════════════════════════
# 25.0.1 es **exactamente** la que nuestro `python3` ya trae empaquetada en
# `ensurepip/_bundled/pip-25.0.1-py3-none-any.whl` (medido). Usar otra pondría dos pips distintos en
# circulación —uno importable y otro que `ensurepip` desplegaría— y el día que algo se comportara
# distinto según cuál tomó, nadie lo encontraría.
#
# Python puro: no compila nada. Se copia `src/pip`, igual que `py3-setuptools` copia `setuptools`.
name    = "py3-pip"
version = "25.0.1"
license = "MIT"

[source]
tarball = "https://files.pythonhosted.org/packages/70/53/b309b4a497b09655cb7e07088966881a57d082f48ac3cb54ea729fd2c6cf/pip-25.0.1.tar.gz"
sha256  = "88f96547ea48b940a3a385494e181e29fb8637898f88d88737c5049780f196ea"

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
link     = "static"
flags    = []

[build.phases]
configure = '''
set -e
[ -d src/pip ] || { echo "py3-pip: el sdist no trae src/pip — upstream cambió el layout" >&2; ls -la >&2; exit 1; }
echo "py3-pip: src/pip presente"
'''
compile = "true"
install = '''
set -e
SP=/out/usr/lib/python3.12/site-packages
mkdir -p "$SP"
cp -r src/pip "$SP/"
# ⚠ El guardián comprueba lo que de verdad importa: que `find_spec("pip")` lo ENCUENTRE, que es la
# pregunta exacta que hace `mkvenv` de qemu. Que el directorio exista no es lo mismo: sin
# `__init__.py` o con un layout distinto, `find_spec` devuelve None y el build de qemu se iría otra
# vez al índice — con un error que no menciona a pip.
[ -f "$SP/pip/__init__.py" ] || { echo "py3-pip: falta pip/__init__.py — find_spec('pip') devolvería None" >&2; ls "$SP/pip" 2>/dev/null | head >&2; exit 1; }
v=$(PYTHONPATH="$SP" python3 -c 'import importlib.util as u, pip; print(pip.__version__ if u.find_spec("pip") else "")' 2>&1) || {
  echo "py3-pip: no se puede importar pip desde el site-packages instalado" >&2; printf '%s\n' "$v" >&2; exit 1
}
[ "$v" = "25.0.1" ] || { echo "py3-pip: la version importada es '$v', esperaba 25.0.1 (la misma que el ensurepip de python3)" >&2; exit 1; }
echo "py3-pip: pip $v importable desde site-packages"
'''

[deps]
build = ["python3"]
# Quien lo use lo IMPORTA en ejecución, no al construirse.
runtime = ["python3"]