Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actualizar la documentación para indicar que el clon debe ser recursivo #3353

Open
wants to merge 6 commits into
base: 3.13
Choose a base branch
from

Conversation

kbiggers
Copy link
Contributor

@kbiggers kbiggers commented Dec 28, 2024

Actualizar la documentación para indicar que el clon debe ser recursivo

closes #3352

Copy link

All entries translated, horray! 🎉

@rtobar
Copy link
Collaborator

rtobar commented Dec 30, 2024

@kbiggers los cambios de este PR están basados en tu branch donde tradujiste lexical_analysis.po. ¿Puedes hacer un rebase sobre la rama 3.13? ¡Gracias!

En cuanto a los cambios mismo, si bien son correctos, creo que no son óptimos. Hacer el clone recursivo es mucho más costoso que hacer el clone sólo de python-docs-es, y para lo único que se necesita el submódulo de cpython es para construir la documentación -- que creo que muchos usuarios no realizarn de forma local. Por otro lado, cuando uno hace make build el submódulo se inicializa si no está inicializado. Dado todo esto,, creo que tienen más sentido otras alternativas donde no se hace un clon recursivo:

  1. Cambiar las instrucciones para que el comando pip install indique que hay que instalar pip install requirements-own.txt en vez de requirements.txt. Ese sería un cambio bien simple, ya que sabemos que el resto de la infraestructura ya funciona con los archivos requirements*.txt tal como están.
  2. Renombrar requirements.txt a requirements-build.txt y requirements-own.txt a requirements.txt. Así queda claro que el primero contiene las dependencias necesarias para hacer el build, mientras que el segundo, más implícitamente, contiene las dependencias que se necesitan para hacer la traducción. Dados los cambios de nombres, se requeriría un par de cambios en los jobs de CI tal vez, y en el Makefile, pero nada muy complejo.

Personalmente yo me decantaría por la primera opción, pero sería bueno escuchar otras opiniones. Y, en primer lugar, saber si ésta es una opción válida en primer lugar.

@kbiggers
Copy link
Contributor Author

kbiggers commented Jan 2, 2025

Gracias por la respuesta @rtobar! Coincido contigo que la opción 1 parece la más simple, y la mejor por ahora. Tal vez podemos añadir algún comentario extra a la guía sobre como construir la documentación de forma local (por si acaso algún usuario quiere hacerlo)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Actualizar la documentación ahora que dependemos de cpython en requirements.txt
2 participants