CI tests the checkout's module, not the installed wheel
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 70/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- github-actions, python
- Área
- ci-cd, testing-qa
Línea de trabajo
Comienza con el workflow de tests y sus comandos actuales de instalación y pytest; después, reproduce la comprobación de importación desde la raíz del repositorio. Verifica que el workflow pruebe el wheel instalado, incluido un wheel sin ipython_pygments_lexers.py; se considera terminado cuando el módulo ausente hace que falle la ejecución de tests en lugar de pasar contra la copia del checkout.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The tests workflow installs the project with python3 -m pip install "." pytest and then runs python3 -m pytest -v from the repository root. Because python -m puts the current directory first on sys.path, and the project is a single top-level module (ipython_pygments_lexers.py) next to its test file, the tests import ipython_pygments_lexers from the checkout rather than from the installed distribution. We observed this with an import probe in a clean container: in every run, the module was loaded from the working tree.
One consequence is that a packaging mistake in the wheel would not fail CI. To check, we built the wheel from the current main (50791e2) and made a copy of it with ipython_pygments_lexers.py removed. We then ran the tests from the repository root against each wheel (Python 3.12, pytest 9.1.1, pygments 2.21.0):
| Command | Intact wheel | Wheel without the module |
|---|---|---|
python -m pytest (the CI command) |
7 passed | 7 passed |
pytest |
7 passed | 7 passed |
pytest --import-mode=importlib |
7 passed | ImportError |
Switching to the pytest entry point alone is not enough. With the default import mode, pytest inserts the test file's directory (the repository root) into sys.path, which again puts the checkout's module first.
If the intention is to test the installed package, running pytest --import-mode=importlib in the workflow makes the tests import the installed copy. If testing the checkout is intended, and the install is only there for the Pygments entry points, please feel free to close this.
We are studying how Python test suites pick the copy of the code they test, and wanted to share the observation.
- Lenguaje dominante
- Python
- Estrellas
- 0
- Forks
- 2
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ipython/ipython-pygments-lexers
-
failure on shell commands after `%%time`Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Todos los issues de ipython/ipython-pygments-lexers
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Juniper/ansible-junos-stdlib#904 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
pollen-robotics/reachy_mini#1457 ·
Los mantenedores suelen responder en 1 día
-
area:runtime good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
WATonomous/wato_f1tenth#39 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
FireDynamics/fdsreader#123 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100