Use lock files and relative dependency cooldowns

Abierto
  • ¿Algo no está bien?
#1 8 comentarios 2 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, shell
Área
build-system, release

Línea de trabajo

Empieza leyendo pyproject.toml y tools/configure_macos_env.sh; después, revisa cómo cibuildwheel obtiene actualmente las dependencias de compilación. Compara los enfoques de archivos de bloqueo de uv y pixi, incluidos los periodos de enfriamiento relativos de las dependencias y la gestión de libomp en macOS; se considera terminado cuando las dependencias de compilación, sdist y pruebas están bloqueadas explícitamente y las actualizaciones están automatizadas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I think the use of requirements files with X.Y.Z pinned version constraints is good but not enough to ensure full reproducibility of the builds (there can be .post0 markers after the .Z component for instance). I think we should use an explicit lock file to manage:

The lockfile(s) should be automatically refreshed, e.g. on a monthly basis with a relative dependency cooldown policy of a week to reduce the exposure of the release process to ongoing OSS Supply Chain attacks.

The lockfile(s) in the release repo could either be managed via uv or pixi. I don't think it matters much because we don't need conda-forge for the build and testing process in this repo. All the Python-level builds dependencies are fetched from pypi.org and the rest come from the system image (e.g. manylinux). EDIT: actually we do fetch a fixed binary for libomp on macOS, so maybe we could use pixi and a lock file to do that more automatically.

When the lock files are updated, we should use relative dependency cooldowns such as uv's exclude-newer config or pixi's exlude-newer config).

Ideally, the build dependencies should also be locked explicitly in the repo as for the other dependencies. According to cibuildwheel's doc, the pip wheel command is used under the hood to setup the build env automatically. By default, it will install dependencies from the pyproject.toml file. However, it should be possible to pass an explicit pylock.toml export of a proper uv managed lockfile to pip wheel -r. Alternatively, we configure cibuildwheel's before-build hook to run a script to explicitly prepare the build environment manually using uv or pixi commands and disable build isolation and run pip wheel --no-build-isolation --no-deps.

Lenguaje dominante
Shell
Estrellas
2
Forks
5
Merge medio
24 min
PR fusionados (30 d)
4

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de scikit-learn/scikit-learn-release

Todos los issues de scikit-learn/scikit-learn-release

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.