Refactor test libraries && update Gestor_Dependencias issue #17

docs/Gestor_Dependencias.md

@@ -1,10 +1,28 @@
 # Elección del gestor de dependencias.
 
+
+
 ## Para qué se necesita un gestor de dependencias.
 
 Como bien se menciona [aquí](https://ibm.github.io/data-science-best-practices/dependency_management.html)
 > 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 [standard de la estructura de los proyectos en Python](https://docs.python-guide.org/writing/structure/) y [este ejemplo de estructura de proyectos](https://packaging.python.org/en/latest/tutorials/packaging-projects/).
+
+La estructura que buscamos tener sería:
+
+- proyecto
+    - LICENSE
+    - pyproject.toml
+    - README.md
+    - src/
+        - paquete_1
+            - __init__.py
+            - ejemplo.py
+    - tests/
+    - .gitignore
+    - Makefile (en este caso el tasks.py con invoke que llama a poetry)
+
 ## 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.
@@ -14,11 +32,11 @@ Como bien se menciona [aquí](https://ibm.github.io/data-science-best-practices/
 
 ## Gestores de dependencias.
 
-- **pip** Herramienta estándar para instalar paquetes de Python y administrar dependencias. Cuando se usa pip para instalar paquetes, recupera automáticamente el paquete y todas sus dependencias del Índice de paquetes de Python (PyPI) y los instala localmente en el sistema. Tiene la desventaja de que no resuelve los conflictos por dependencias. Usa un fichero.txt, en este caso requeriments.txt. Esto hace que todos los paquetes se guarden con versiones exactas, las actualizaciones tendrían que realizarse manualmente. A medida que avanza un proyecto es más lioso y se necesita de tiempo para mantener al día con los paquetes.
+- **pip** Herramienta estándar para instalar paquetes de Python y administrar dependencias. Cuando se usa pip para instalar paquetes, recupera automáticamente el paquete y todas sus dependencias del Índice de paquetes de Python (PyPI) y los instala localmente en el sistema. Tiene la desventaja de que no resuelve los conflictos por dependencias. Usa un fichero.txt, en este caso requeriments.txt. Esto hace que todos los paquetes se guarden con versiones exactas, las actualizaciones tendrían que realizarse manualmente. A medida que avanza un proyecto es más lioso y se necesita de tiempo para mantener al día con los paquetes. En el caso de pip se usa un pipfile.lock pero se usa con pipenv, que en este caso, no nos interesa.
 
 - **Conda** 
 Es un paquete, dependencia y herramienta de gestión del entorno para Anaconda Python. Algunas de sus características básicas son similares a Pip, Virtualenv y Venv. Sin embargo, es una herramienta separada y mejorada diseñada para funcionar solo en entornos Conda.
-Conda no solo proporciona entornos virtuales que aíslan o encajan cada proyecto para evitar conflictos de dependencia entre ellos; analiza cada paquete en busca de dependencias compatibles y posibles conflictos durante la instalación. Si hay un conflicto, Conda informa o indica que la instalación no se puede completar.
+Conda no solo proporciona entornos virtuales que aíslan o encajan cada proyecto para evitar conflictos de dependencia entre ellos; analiza cada paquete en busca de dependencias compatibles y posibles conflictos durante la instalación. Si hay un conflicto, Conda informa o indica que la instalación no se puede completar. No genera ficheros .lock, para ello se necesitaría de [conda lock](https://anaconda.org/conda-forge/conda-lock)
 
 
 - **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

tests/test_pmp_iv.py

@@ -1,13 +1,13 @@
-from pmp_iv.utils.validation import *
-from pmp_iv.models.coordenada import *
-from pmp_iv.models.fecha import *
-from pmp_iv.models.estado import *
-from pmp_iv.models.fwi import *
-from pmp_iv.enums.day import *
-from pmp_iv.enums.month import *
+import pmp_iv.utils.validation 
+import pmp_iv.models.fecha 
+import pmp_iv.models.estado 
+import pmp_iv.models.fwi 
+import pmp_iv.enums.day 
+import pmp_iv.enums.month
+import pmp_iv.models.coordenada
 
 def test():
-    assert Coordenada(5,5)
-    assert Fecha(Month.julio,Day.L)
-    assert Estado(10,10,9,3,200)
-    assert FWI(30.4,124.5,664.9,32.6)
+    assert pmp_iv.models.coordenada.Coordenada(5,5)
+    assert pmp_iv.models.fecha.Fecha(pmp_iv.enums.month.Month.julio,pmp_iv.enums.day.Day.L)
+    assert pmp_iv.models.estado.Estado(10,10,9,3,200)
+    assert pmp_iv.models.fwi.FWI(30.4,124.5,664.9,32.6)