tests missing in sdist/ incoherent tagging vs tarball naming
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- build-system, release
Línea de trabajo
Comienza comparando MANIFEST.in y setup.py con el sdist publicado en PyPI y con un archivo generado localmente a partir de release-2.2019-12-21. Rastrea cómo se generan la etiqueta de release y los nombres de los archivos. Se considera terminado cuando el sdist publicado contiene los archivos de prueba y los nombres de la etiqueta y de la distribución siguen un esquema documentado y coherente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hi! I'm packaging python-publisuffx2 for Arch Linux and would like to be able to run tests from the sdist tarball on pypi.
Although the test files should be included (according to MANIFEST.in), they are not.
As a test I've checked out the current latest version (release-2.2019-12-21) and ran python setup.py sdist myself. The files are included in the created sdist tarball, which makes me wonder how the sdists for pypi.org were created.
It would be great, if the sdists included the tests, as currently I have to use the github tarballs to be able to run the tests.
This leads me to the second topic: The tag naming and resulting tarballs are incoherent and lead to more complicated string substitutions to track upstream and/or use the github source tarball vs. using pypi's sdist tarball: release-2.2019-12-21 -> publicsuffix2-2.20191221.tar.gz
I understand, that the tagging scheme so far follows an ISO standard for the date, but it would be more coherent to strip the hyphens to be in line with the resulting tarball/wheel: e.g. release-2.20191221 -> publicsuffix2-2.20191221.tar.gz
- Lenguaje dominante
- Python
- Estrellas
- 30
- Forks
- 16
- 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 aboutcode-org/python-publicsuffix2
-
codes.open is deprecated in python3.14Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 52/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 55/100
-
Mislabeling of eTLD-`n`Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
aboutcode-org/python-publicsuffix2#23 · 1 comentario · 1 reacción ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
aboutcode-org/python-publicsuffix2#21 · 1 reacción ·
Todos los issues de aboutcode-org/python-publicsuffix2
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Graphify-Labs/graphify#4860 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
:bug: Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
scikit-image/scikit-image#8377 ·
Los mantenedores suelen responder en 1 día
-
Ingredient import validation accepts negative nutrient values and NaNPosiblemente ocupada @LukeSekai la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
wger-project/wger#2564 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apache/ponymail-foal#351 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
Los mantenedores suelen responder en 4 días