Typo en la sección de install, check y test de la documentación

Como parte del desarrollo del #35 la versión puesta en el dockerfile es la:

name: Log in to Docker Hub
uses: docker/login-action@v1

Según lo visto en esta página, tendría que ser la versión 2, de forma que sería:

name: Login to Docker Hub
uses: docker/login-action@v2

Tras hablar con @JJ, hemos visto que sería interesante conocer un poco más el significado de la clase así como de sus propiedades, para saber que es cada una y poder hacer un docstring en cada elemento. Te adjunto el enlace al fichero de la clase:

https://github.com/arsa-dev/PMP_IV/blob/ar-implement-objetivo-2/pmp_iv/models/estado.py

De acuerdo a la HU #7, y el objetivo 5 necesito usar flujos de trabajo con github para la imagen creada en #34 y elegida en #33

Como parte del desarrollo del #7 y del objetivo 6, se tienen que elegir un sistema de integración continua.

Criterios a tener en cuenta

• Gratuito o freemium
• Compatible con github check api.
• Pueda servir para poder testear lo realizado previamente con docker en el objetivo 5 y se puedan lanzar los tests con las distintas versiones.

Algunos de los sistemas de integración continua:

• Github actions: Tiene un nivel gratuito, sirve con github check y es útil porque se puede usar con Docker y con python, la documentación además es muy extensa y buena.
• CircleCi: Compatible con muchos lenguajes, entre los cuales python, tiene como control de versiones Github, es una de las herramientas más tulizadas de DevOps, no es gratuita, pero ofrece un nivel gratuito que nos sirve para el desarrollo de la práctica.
• Jekins: Tiene el inconveniente de que requiere de una instalación de hardware propio, automatización de código abierto para integración continua, simple instalación y actualizaciones, pero es de pago si se quieren hacer scripts personalizados.
• AppVeyor: Compatible para python, sirve para entorno de trabajos como es el caso de Github, es gratuita para proyectos de código abierto, pero tiene un límite de 14 días.

Finalmente, se ha decidido por emplear CircleCI con docker y Github Actions para el control de versiones del proyecto.

Debido a lo realizado en #39, al iniciar compilar docker genera el siguiente warning:

Warning: poetry.lock is not consistent with pyproject.toml. You may be getting improper dependencies. Run `poetry lock [--no-update]` to fix it.

Para ello se ha ejecutado para quitar este mensaje de warning.

poetry lock --no-update

Teniendo en cuenta que para el desarrollo del milestone 1 de la HU1 #7, se pide aplicar modelo de regresión sobre los datos del issue #25, tengo que elegir distintos algoritmos de regresión y atendiendo a los que se quiere hacer en #27, los elegidos son:

• Lasso.
• Ridge.
• KNeighborsRegressor.
• RandomForestRegressor.

Todos estos se pueden usar con la librería elegida en #27

Teniendo en cuenta #7, se necesita un gestor de dependencias como parte del objetivo 3.

Elección del gestor de dependencias.

Para qué se necesita un gestor de dependencias.

Como bien se menciona aquí

Dependency management is like your city’s sewage system. When it’s working well, it’s easy to forget that it even exists. The only time you’ll remember it is when you experience the agony induced by its failure.

Teniendo en cuenta el estándar de la estructura de los proyectos en Python y este ejemplo de estructura de proyectos.

La estructura que buscamos tener sería:

• proyecto
  • pyproject.toml
  • README.md
  • proyecto/
    • init.py
  • tests/
    • init.py

Mejores prácticas para la gestión de dependencias de python.

• Debe de ser estable en todos los entornos en los que se trabaje.
• Debe de ser fácil de instalar, compilar y ejecutar.
• Evitar el 'Dependency Hell', este concepto se asocia cuando se intenta resolver conflictos por dependencias. Esto ocurre cuando diferentes paquetes de Python tienen la misma dependencia, pero dependiendo de versiones distintas e incompatibles de un paquete compartido.
• Creación de un fichero lock, para asegurar que las dependencias sigan fijadas a las versiones exactas en uso.
• Tener todas las dependencias en un único fichero en lugar de tenerlo individualmente.
• Seguir el estándar de PEP 518.
• En este caso seguir el estándar PEP 621 para el fichero pyproject.toml

Gestores de dependencias.

• PDM Instala y gestiona paquetes de manera similar a npm que no necesita crear un virtualenv. Soporta el PEP 582, sigue los estándares de python. Sistema flexible y potente. Cache de instalación centralizado como pnpm. De igual modo, a la hora crear un proyecto sigue el estándar y genera una estructura útil

• hatch Es una herramienta útil para el aislamiento del entorno y destinado a administrar dependencias. Tiene un sistema de complementos que hace fácil su funcionalidad. Sistema de compilación estandarizado con compliaciones de manera predeterminada. Sigue el estándar de la estructura de proyectos.

• poetry Es una herramienta de dependencia y gestión de python, usa sistema de archivos de bloqueo para compiladores. Garantiza que se esté usando un entorno virtual, por lo que evita errores de instalaciones globales. Puede declarar sus dependencias por medio de la shell o en el fichero pyproject.toml
  Las dependencias del proyecto se gestionan en el pyproject.toml, que se actualiza automáticamente cada vez que se ejecuta el comando de instalación de poetry. Genera del mismo modo un fichero lock. Tiende a ser más rápido. Sigue el estandar de la estructura de los projectos de python como se puede ver en este ejemplo a la hora de crear un proyecto con poetry, ya que genera un fichero .toml, Readme.md, directorio para los .py y otro para los test.

Se ha optado por poetry por:

• Seguir el estándar de la 'Specifying Minimum Build System Requirements for Python Projects'.
• Documentación oficial muy sencilla.
• Mejor visión de las dependencias al usar un fichero(pyproject.toml).
• Tiene un entorno virtual integrado.
• Construcción sencilla.
• Permite cambiar fácilmente entre versiones.
• Rendimiento.

Tras hablar con @JJ, hemos visto que sería interesante conocer un poco más el significado de la clase así como de sus propiedades, para saber que es cada una y poder hacer un docstring en cada elemento. Te adjunto el enlace al fichero de la clase:

https://github.com/arsa-dev/PMP_IV/blob/ar-implement-objetivo-2/pmp_iv/models/coordenada.py

Teniendo en cuenta los 4 niveles de incendios forestales que existen, siguiendo el Plan INFOEX los niveles son:

• Incendios de nivel 0: los que no suponen peligro para bienes y personas y se considera que se controlarán con los medios del Plan INFOEX.
• Incendios de nivel 1: los que pueden ser controlados por los medios del Plan, pero pueden afectar a personas o bienes de carácter no forestal.
• Incendios de nivel 2: aquellos en los que se considera necesaria la intervención de medios estatales no asignados al Plan INFOEX o puedan comportar situaciones de emergencia de carácter nacional.
• Incendios de nivel 3: los que así sean declarados por el Ministerio del Interior por estar en juego el interés nacional.

Se quiere obtener directamente el dato del nivel de riesgo de incendio que puede existir en la zona por medio de un documento en formato PDF con los gráficos y estudios realizados demostrando el nivel de riesgo.

El nivel de riesgo se tiene que estimar estudiando la proximidad entre las cercanías de los incendios de la zona, ya que no es el mismo riesgo que haya un incendio en una zona en un punto 'a' y otro en un punto 'b' y haya una distancia muy grande a un incendio en un punto 'c' y otro 'd' que son puntos próximos entre si.

Para esto se necesita del milestone [M2] que a su vez. depende del 1 y del 0.

Una vez creada la imagen de docker #34 y funcionando los tests genera un aviso de que intenta escribir ficheros, pero no tiene permitido, estos son los de caché, pero para ello se ha arreglado en el issue #38, para evitar que aparezca este mensaje en el fichero pyproject.toml:

[tool.pytest.ini_options]
filterwarnings = [
    "ignore::UserWarning",
]

Como parte del desarrollo del #7 y del #47, se debe incluir en el iv.yaml un path, quedando así lo que hay que añadir:

CI: .circleci/config.yml

Como parte del desarrollo de la #7 y del #48
Se quiere arreglar el error que produce en github actions al no detectar a invoke

Partiendo de la necesidad del HU0 #7, se necesita a partir de la clase EDA que se requiere en el issue #25, se quiere implementar una clase que estime la correlación entre los datos sesgados.

Se quiere implementar la correlación de Pearson con la fórmula de la siguiente página

Al usar la última versión de la imagen de python de docker genera el siguiente problema:

AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 'getargs'?

Visto lo mencionado el issue del github de invoke #833, la última versión con la que trabaja invoke es la 3.9, por lo que se usará esta versión para la imagen de Docker

De acuerdo a la HU #7, y el objetivo 5 necesito crear una imagen basándose en los criterios establecidos en el objetivo y la elección hecha en el issue #33

Dado que se usa poetry con docker, se necesita crear un entorno virtual env como en el siguiente caso

Con invoke necesito comprobar la sintaxis de los ficheros '*.py'

Tras hablar con @JJ, hemos visto que sería interesante conocer un poco más el significado de la clase así como de sus propiedades, para saber que es cada una y poder hacer un docstring en cada elemento. Te adjunto el enlace al fichero de la clase:

https://github.com/arsa-dev/PMP_IV/blob/ar-implement-objetivo-2/pmp_iv/models/fecha.py

Para verificar que ha funcionado todo lo realizado, necesito testearlo y guardarlo en el README.md para dejar constancia de que los test dan el visto bueno de lo pedido en #25, #26, #30.

Se quiere eliminar los datos que no aporten nada

Como parte de la HU0 #7, y el milestone 1, se necesita de una clase que maneje los datos del csv de incendios, siendo así las necesidades principales:

• Extraer datos de una columna específica dependiendo del día y mes.
• idem sin día y mes.
• Todos los datos relacionados con el clima(no se necesitan ni coordenadas ni mes y día)

Todos estos datos sesgados son necesarios para el #26

Como parte del desarrollo de la #7 y del #46
Se debe implementar un workflow para github actions que maneje una matriz de versiones, en este caso se eligen la 3.7 y 3.8, no se usa la 3.9 porque es la que usa docker por defecto y versiones anteriores no se pueden emplear por incompatibilidades con los gestores de tareas y dependencias.

Hola @MauronMP,

ya veo que está aprobado el PR #4, por lo que puedes mergearlo aunque haya algún punto que mejorar tal y como comenta @JJ.

Abro hilo de discusión para definir la tecnología y comenzar el desarrollo del objetivo 2 en un nuevo PR. ¿En qué tecnología crees que es mejor desarrollar tu proyecto? ¿Tienes alguna buena práctica o consideración a tener en cuenta de cara a la implementación además de lo que se especifica en el M0?

Teniendo en cuenta #7, se necesita un gestor de tareas como parte del objetivo 3.

Elección del gestor de tareas.

Las opciones son Doit, Invoke y Pypyr.

• Doit Tiene como idea usarse como un simple Task Runner que permita definir tareas 'ad hoc', unificando. Las dependencias y la creación de las tareas se pueden hacer dinámicamente durante su ejecución, lo que lo hace adecuado para conducir flujos de trabajo y pipelines complejas.

• Invoke Como bien se menciona aquí, en los gestores de tareas hay distintos tipos, entre los que nos fijamos entre estándar u opcionales. En el caso de python hace falta de una herramienta externa, como es el caso de invoke. Está inspirado en varias fuentes como make/rake entre otros y tiene así un conjunto de características potentes y limpias. Con invoke se puede definir y ejecutar funciones de tareas, crear pre-tareas, ejecutar comandos de shell entre otras opciones.

• Pypyr Permite definir y ejecutar pasos secuenciales en un pipeline. Como un script de shell ,más sencillo que un archivo MAKE. Ejecuta pipelines definidas en yaml. Da una sencilla sustitución de variables y gestión de archivos de configuración para que se pueda leer, fusionar y escribir archivos de configuración desde y hacia yaml, json o simplemente texto.

Se ha optado por Invoke por su simplicidad y documentación.

Como parte del desarrollo del milestone 1 y de la HU1 #7, a partir de la clase creada por #26 y los algoritmos elegidos en #28, necesito tener almacenado los nombres de los algoritmos que he usado y dar así como resultado del #26 el nombre del algoritmo que ha tenido mejor valoración, para ello usaré un enum

Dentro del fichero de poetry hay un duplicado de la línea:

invoke = "^1.7.3"

en la línea de

[tool.poetry.dependencies]

Tiene que estar solo en:

[tool.poetry.dev-dependencies]

Tras hablar en clase con @JJ, hemos visto que sería interesante sacar a un fichero de configuración todas las constantes que tenemos para validación en los modelos, así se podrían ajustar esas constantes en diferentes instalaciones o si en algún momento cambiara algún valor, como por ejemplo el máximo de 45º de temperatura en un verano intenso. ¿Que te parece si creo un fichero en el módulo pmp_iv.config que contenga todas las constantes y luego se usen para la validación?

Como parte del objetivo 4 y teniendo en cuenta la #7, se necesita una biblioteca de aserciones.

Elección de una biblioteca de aserción.

Vamos a partir de las valoraciones de esta página. Que hace una comparativa de cada librería para un proyecto para distintos lenguajes, en este caso python.

Opciones.

• grappa Tiene como finalidad hacer que las pruebas sean más sencillas. Tiene dos tipos de asserciones: "expect y should". Tiene un sistema detallado de informes de errores "amigable". Pero tiene una mala valoración y apenas hay documentación o ejemplos además de la oficial.

• assertpy Tiene un buen soporte para poder trabajar con estructuras nativas de python como list, set o dict entre otros. Tiene personalización de los mensajes de aserciones, aunque la valoración que tiene sigue siendo mala, aunque mejor que la anterior.

• 🏁 pyhamcrest Permite definir de manera clara las reglas, tiene un buen manejo de los mensajes de errores y ayuda así a una mejor comprensión. Tiene una amplia documentación y cuenta con muchos "matchers" predefinidos.

Como parte de la HU1 #7, se necesita elegir una biblioteca para poder aplicar algoritmos de regresión en los datos de la clase eda correspondiente al issue #25, por ello para desarrollar la clase del #26 se va a usar la librería sklearn para aplicar algoritmos de regresión sobre los datos sesgados del issue #25

A partir de los datos de la siguiente página, se necesita elegir una librería y funcionalidades para poder extraer y sesgar todos los datos en distintos marcos para poder comenzar con el milestone M1 referente a las HU0 #7.

Partiendo de estas necesidades, python ya tiene un módulo específico para ficheros csv, se usará este.

Para leer los datos usando esta librería se usará con la opción de 'DictReader', ya que permite trabajar con los nombres de las columnas como índices.

Como parte del objetivo 4 y teniendo en cuenta la #7, se necesita un test-runner.

Elección de un test runner.

Vamos a partir de las valoraciones de esta página. Que hace una comparativa de cada librería para un proyecto para distintos lenguajes, en este caso python.

Opciones.

• 🏁 PyTest Partiendo que tiene la mejor valoración. Sigue el estándar del formato TAP. Tiene como características la búsqueda automática de ficheros con nombre "test" o sufijo "_test.py", la creación de los test es bastante sencilla, permite parametrización, tiene Hooks que son útiles en las fases de setup y teardown.

• Nose2 EL sucesor de nose, tiene buena valoración, pero es menor que la de pytest. Basado en unittest2 con mejores opciones de testeo, en este caso solo ejecutará los ficheros que empiecen por "test_". Tiene menos popularidad, soporte y es como una "extensión mejorada" de unittest.

Como parte del #7, en el milestone 1 con los datos de la clase #25 y #26, tengo que dividirlos en dos partes, una como testeo y otra 'entrenada', para eso usando la librería elegida en #27, en el constructor de la clase #26, tendré sesgado por un lado el 20% de los datos para testear.

Una vez tenga los dos datos segmentados tengo que estandarizar los datos, eliminando la media y escalando los datos de forma que su varianza sea igual a 1. Para ello usaré de la librería #27 'StandardScaler'

Como parte del desarrollo del #7 y del #46 se usará circleci

De acuerdo a la HU #7, y el objetivo 5 necesito elegir un contenedor base.

Elección de la imagen de docker.

¿Qué se busca en una imagen?

• Estabilidad.
• Tamaño de la imagen.
• Actualizado al día con el lenguaje, en este caso python.
• Actualizada las dependencias.

Partimos de dos caminos:

• Oficiales de docker

  • Alpine. Útil para imágenes pequeñas, pero puede conllevar a errores de rendimiento y tamaño por la gestión de paquetes.
  • Slim. Carece de las capas en los paquetes comunes, por lo que hace que sea una imagen mucho más pequeña.
  • Bullseye. Tiene muchos paquetes instalados por capas de imagen que usan otras imágenes de docker, lo que hace que el uso del disco sea bajo.

• Otras

  • Ubuntu. Imagen muy pesada en comparación con las anteriores y tiene muchos paquetes instalados que no son necesarios para este proyecto.
  • Debian. Más liviana que la anterior, pero para usar Debian es más conveniente usar una versión de las oficiales de python que usan Debian de manera más liviana, como el caso de la versión bullseye.
  • bitnami Esta será la elegida. Además de que es una imagen más ligera que las demás mencionadas, buen rendimiento, muchas descargas en dockerhub, cuenta además con el 'VERIFIED PUBLISHER' de dockerhub en python. Otro motivo ajeno es diferenciarse de las oficiales de python que serán elegidas por otros compañeros...

Finalmente, se ha elegido bitnami, en este caso la 3.9 ya que genera problemas con invoke, puesto que tanto invoke como nose2, opciones barajadas como tasks runners trabajan hasta las versiones 3.9 de python, pero las versiones de docker de python a partir de las 3.10 en adelante genera problemas por depenencias que los test runners no disponen.

Para solventar esto, se ejecutará en el Dockerfile #34 la siguiente orden:

RUN export PYTHONDONTWRITEBYTECODE=1

Para consultar

Además, en esta refactorización, se ha eliminado el fichero main, para poder probar la instanciación de las clases se podría añadir un main con nombre testmain_* (ignorado en el repositorio), como el siguiente:

from pmp_iv.models.fwi import FWI
from pmp_iv.models.fecha import Fecha,Months,Day
from pmp_iv.models.coordenada import Coordenada
from pmp_iv.models.estado import Estado

fwi_instance = FWI(34.4, 44.4, 17.7, 14.3)
print(fwi_instance)

fecha_instance = Fecha(Months.enero, Day.M)
print(fecha_instance)

coordenada_instance = Coordenada(3, 4)
print(coordenada_instance)

coordenada_instance = Estado(-7, 50, 7, 5, 17)
print(coordenada_instance)

Se quiere evitar ficheros basura en el docker, en este caso el pyproject.toml y el poetry.lock.
Para ello se eliminarán una vez se instale las dependencias.

Como ejemplo de cómo lo haré será parecido al siguiente

Related to #8. Cito discusión sobre implementación

@arsa-dev

Hola @MauronMP, he implementado las clases definidas en el M0, aunque para las definiciones 4 a 8 no tengo muy claro que eso sean clases, parecen más simplemente validación de valores pero no sabría en que clase o lugar habría que definirlos. O debo de crearlas como clases con una única propiedad por ejemplo value y que cuente con esa validación.

Quedo a la espera de si es necesario implementar esto, en caso de no serlo ya estaría el PR listo en #9

@MauronMP

Buenas @arsa-dev, he visto los ficheros que has creado, de momento me parece que están bien, igualmente necesito comprobarlo y mirarlo con más detenimiento. Respecto a los cambios que mencionó JJ, los cambiaré.
Lo único que si me haría falta es que crees el issue como ha mencionado y respecto a lo que mencionas de las definiciones 4 a 8, siguiendo la manera del fwi.py que has creado podrías hacer algo parecido con las definiciones del 4 al 8.

Tras hablar presencialmente, se ha decidido crear una clase llamada estado con las propiedades de 4 a 8

Tras hablar con @JJ, hemos visto que sería interesante conocer un poco más el significado de la clase así como de sus propiedades, para saber que es cada una y poder hacer un docstring en cada elemento. Te adjunto el enlace al fichero de la clase:

https://github.com/arsa-dev/PMP_IV/blob/ar-implement-objetivo-2/pmp_iv/models/fwi.py