Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Windows install of pylock.toml fails on the pipeline extra due to missing Windows wheel for python-dp

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

Los mantenedores suelen responder en 2 días

@Khprateek ya está trabajando en esto.

Desde el 27/9/2026.

  • #211 de @Khprateek — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, python
Área
documentation, operating-systems

Línea de trabajo

Start with CONTRIBUTING.md and review the current environment setup, activation commands, and pylock.toml installation guidance. Check the documented Windows, WSL2, and Docker paths against the reported commands and dependency limitations. Done means the guide gives platform-specific commands and clearly states native Windows pipeline limitations and the supported full-development workflow.

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

Descripción

Environment

  • OS: Windows 11, Version 25H2 (OS Build 26200.9457)
  • uv version: 0.12.19 (bea138450 2026-09-24 x86_64-pc-windows-msvc)
  • Python: 3.12 (per uv venv --python 3.12)

Problem

Following the Windows development setup in CONTRIBUTING.md, installing the committed pylock.toml fails because the pipeline extra includes pipeline-dp, which depends on python-dp.

python-dp does not currently publish a Windows wheel for any released version — see its PyPI files page, which currently lists only manylinux_2_27_x86_64, manylinux_2_28_x86_64, and macosx_15_0_universal2. Its README has said "Windows support coming soon" since at least August 2020, and a 2020 milestone tracking cross-platform support was closed as complete without a Windows wheel ever shipping — so this doesn't look close to landing upstream.

So:

uv pip install -r pylock.toml

fails on native Windows.

This affects Windows contributors even if they do not intend to use the pipeline functionality, because the committed lockfile is generated with --all-extras.

Steps to reproduce

On Windows:

uv venv --python 3.12
uv pip install -r pylock.toml

Observed error:

error: Package `python-dp` can't be installed because it doesn't have a source distribution or wheel for the current platform
hint: You're on Windows (`win_amd64`), but `python-dp` (v1.1.5) only has wheels for the following platforms: `manylinux_2_27_x86_64`, `manylinux_2_28_x86_64`, `macosx_15_0_universal2`; consider adding "sys_platform == 'win32' and platform_machine == 'AMD64'" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels

(Tested via -r pylock.toml; I haven't separately confirmed whether uv pip install -e ".[pipeline]" hits the identical error, though I'd expect so given the same underlying dependency.)

Investigation

I tested gating pipeline-dp with:

sys_platform != 'win32'

This allows the dependency resolution and installation to complete on Windows, while Linux/macOS remain unaffected.

However, this is not a fix by itself.

apache_beam, pipeline_dp, and tensorflow are imported at module level in dpsynth/data_generation.py and in dpsynth/pipeline_transformations/.

For example, with a bare Windows installation without the pipeline dependencies:

import dpsynth

succeeds, but:

import dpsynth.data_generation

fails immediately with:

ModuleNotFoundError: No module named 'apache_beam'

I also tested the corresponding environment under WSL/Ubuntu with the pipeline dependencies installed:

import dpsynth.data_generation
from dpsynth.pipeline_transformations import aim

Both imports succeed.

This means simply excluding pipeline-dp on Windows could result in an environment that appears installable but fails when users import functionality that currently imports these dependencies eagerly.

Relation to #151 / #152

This appears related to the eager-import issue being addressed for TensorFlow in #151/#152.

The same general pattern seems to apply more broadly to apache_beam / pipeline_dp: these dependencies are imported at module level rather than only when the relevant functionality is used.

I am not proposing to expand #151/#152 in this issue. I mainly wanted to document that the dependency/import problem appears to extend beyond TensorFlow.

Proposed documentation update

Given that the underlying lazy-import work may take some time, I'd propose making the development instructions platform-specific and directing Windows users to WSL2 or Docker for the full development environment:

  • Linux/macOS: continue using the committed pylock.toml, unchanged.
  • Windows: use WSL2 or a Docker dev container for the full environment, including the pipeline extra.
  • Native Windows (no WSL2/Docker): document that the pipeline extra cannot currently be installed and that the pipeline-related modules (dpsynth.data_generation, dpsynth.pipeline_transformations) are therefore unavailable.

This avoids introducing a platform marker that would produce an apparently successful but incomplete installation.

This is also worth doing independent of how the pipeline/python-dp issue is eventually resolved. The current setup steps already assume a Unix shell — for example, source .venv/bin/activate has no Windows equivalent noted (.venv\Scripts\activate on PowerShell/cmd), and uv venv/uv pip command syntax can differ across shells too. Even if the eager-import problem is fixed and/or python-dp eventually ships Windows wheels, Windows contributors would still need correct platform-specific commands to follow the guide. So a dedicated Windows section stands on its own merits, not only as a stopgap for the current install failure.

I'd like to prepare the CONTRIBUTING.md PR for this — a WSL2/Docker-first Windows section, plus the missing Windows activation command — and can open it once this issue is filed.

Expected outcome

Ideally, Windows contributors should have a documented and reproducible development path — including correct platform-specific commands — either through native Windows support for the relevant dependencies or through an explicitly documented WSL2 workflow while the dependency/import issue is being addressed.

Related: #151 , #152

Lenguaje dominante
Python
Estrellas
32
Forks
13
Merge medio
1 d 19 h
PR fusionados (30 d)
20

Preparar el entorno

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 google/dpsynth

Todos los issues de google/dpsynth

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.