sergio/takana

1# py3-pip 25.0.1 — el instalador de paquetes de Python, como MÓDULO IMPORTABLE del sistema.
2#
3# ══ POR QUÉ EXISTE, Y NO ES PARA INSTALAR NADA DE INTERNET ══════════════════════════════════════
4# Esta distro no baja paquetes de PyPI: el sandbox de `takana build` no tiene red, y eso es
5# deliberado. `pip` entra por una razón distinta y precisa: **hay builds que preguntan si `pip`
6# existe y cambian de camino según la respuesta.**
7#
8# El caso medido es `qemu` (2026-10-20). Su `configure` crea un entorno virtual y decide así
9# (`python/scripts/mkvenv.py:244-251`):
10#
11#     if system_site_packages and not need_ensurepip():
12#         kwargs["with_pip"] = False        # ← usa el pip y setuptools DEL SISTEMA
13#     else:
14#         check_ensurepip()                 # ← crea su propio pip y acaba yendo al índice
15#
16# y `need_ensurepip()` es literalmente `find_spec("setuptools") and find_spec("pip")`. Con
17# `py3-setuptools` puesto pero sin `pip` importable, qemu tomaba la segunda rama y moría así:
18#
19#     ERROR: Could not find a version that satisfies the requirement setuptools>=44.1.1
20#            (from versions: none)
21#
22# ⚠ Y el detalle que lo hace inevitable: **en Python 3.12 `ensurepip` ya NO incluye setuptools**,
23# sólo pip. Así que la rama del `ensurepip` nunca puede completarse sin red, por mucho que
24# setuptools esté instalado en el sistema — el venv que crea no lo hereda.
25#
26# ⇒ Con `pip` importable, qemu toma la PRIMERA rama, no crea pip propio, y resuelve su wheel
27# vendorizado (`python/wheels/qemu_qmp-0.0.6-py3-none-any.whl`) con el pip del sistema. Sin red.
28#
29# ══ LA VERSIÓN NO ES «LA ÚLTIMA» A PROPÓSITO ═══════════════════════════════════════════════════
30# 25.0.1 es **exactamente** la que nuestro `python3` ya trae empaquetada en
31# `ensurepip/_bundled/pip-25.0.1-py3-none-any.whl` (medido). Usar otra pondría dos pips distintos en
32# circulación —uno importable y otro que `ensurepip` desplegaría— y el día que algo se comportara
33# distinto según cuál tomó, nadie lo encontraría.
34#
35# Python puro: no compila nada. Se copia `src/pip`, igual que `py3-setuptools` copia `setuptools`.
36name    = "py3-pip"
37version = "25.0.1"
38license = "MIT"
39
40[source]
41tarball = "https://files.pythonhosted.org/packages/70/53/b309b4a497b09655cb7e07088966881a57d082f48ac3cb54ea729fd2c6cf/pip-25.0.1.tar.gz"
42sha256  = "88f96547ea48b940a3a385494e181e29fb8637898f88d88737c5049780f196ea"
43
44[build]
45compiler = "zig-cc"
46target   = "x86_64-linux-musl"
47link     = "static"
48flags    = []
49
50[build.phases]
51configure = '''
52set -e
53[ -d src/pip ] || { echo "py3-pip: el sdist no trae src/pip — upstream cambió el layout" >&2; ls -la >&2; exit 1; }
54echo "py3-pip: src/pip presente"
55'''
56compile = "true"
57install = '''
58set -e
59SP=/out/usr/lib/python3.12/site-packages
60mkdir -p "$SP"
61cp -r src/pip "$SP/"
62# ⚠ El guardián comprueba lo que de verdad importa: que `find_spec("pip")` lo ENCUENTRE, que es la
63# pregunta exacta que hace `mkvenv` de qemu. Que el directorio exista no es lo mismo: sin
64# `__init__.py` o con un layout distinto, `find_spec` devuelve None y el build de qemu se iría otra
65# vez al índice — con un error que no menciona a pip.
66[ -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; }
67v=$(PYTHONPATH="$SP" python3 -c 'import importlib.util as u, pip; print(pip.__version__ if u.find_spec("pip") else "")' 2>&1) || {
68  echo "py3-pip: no se puede importar pip desde el site-packages instalado" >&2; printf '%s\n' "$v" >&2; exit 1
69}
70[ "$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; }
71echo "py3-pip: pip $v importable desde site-packages"
72'''
73
74[deps]
75build = ["python3"]
76# Quien lo use lo IMPORTA en ejecución, no al construirse.
77runtime = ["python3"]