Directorio repo en lugar incorrecto

[N3koSempai]

Al parecer en algún momento realice un cambio de la dirección donde se crea el directorio repo que contiene al archivo repositorio. Comportamiento actual: actualmente se crea la carpeta en el mismo directorio del proyecto del usuario siendo esta una posición innecesaria donde termina siendo basura en el espacio de trabajo del usuario.

comportamiento esperado: debería crearse la carpeta pero dentro de la propia ubicación de la librería LAP en site-packages siendo así invisible para el usuario y sin molestar en su espacio de trabajo

[FrankC64]

Me puse a ver el código de Latino y probar su funcionamiento y considero que sería mucho trabajo hacer que el lenguaje encuentre las librerías y módulo en site-packages, lo mejor sería utilizar la propia forma de Latino. Latino dentro de su código al momento de buscar los módulos consulta la variable de entorno LATINO_LIB y todos los módulos que estén ahí pueden ser incluidos a excepción de las librerías compartidas, con LAP se podría hacer que los módulos se guarden ahí facilitando la inclusión y se podría dejar la forma actual de crear una carpeta "modulo" y dentro de ella guardar todos los módulos descargados, pero para que esto sea viable hay que resolver varios problemas.

Primer problema: En Windows por defecto Latino se instala en "Archivos de Programas" y ¿cuál es el problema? Qué LATINO_LIB apunta a una ruta que está dentro de la ruta de instalación de Latino, por lo que sí o sí para instalar un módulo habrá que iniciar cmd con permisos de administrador.

Segundo problema: En Linux la variable LATINO_LIB no se define por lo que para sanar este problema al momento de querer instalar un módulo habrá que comprobar dicha variable y tomar una decisión, o nosotros mismo definimos una ruta para la variable o que el usuario establezca la ruta que desea que para mí sería lo menos recomendado Yo estoy a favor de que LATINO_LIB apunte a "/home/usuario/.latino" y cuando LAP detecte que LATINO_LIB no se encuentre definida automáticamente cree la variable y la ponga en "~/.profile".

Y tercer problema: LAP tendrá que leer el contenido del zip antes de descomprimirlo, ya que haciendo pruebas si las librerías compartidas (.dll y .so) no están en una ruta en específico, no pueden ser incluidas por Latino, en caso de Windows las dll deben ser instaladas en la subcarpeta "bin" de Latino y en Linux por defecto al compilar una librería siguiendo el ejemplo de Latino: https://github.com/lenguaje-latino/latino-lib-ejemplo, la librería será instalada en "/usr/local/lib" por lo que LAP deberá hacer lo mismo.

Y un problema extra que me ha surgido en Lubuntu y AntiX y no sé si pase en otras distribuciones, es que las librerías en "/usr/local/lib" no se cargan a no ser que esta ruta esté agregada a LD_LIBRARY_PATH por lo que me imagino que LAP tendrá que tomar también eso en consideración.

Si no tienes una nueva versión en desarrollo actualmente, yo podría trabajar en solucionar todos estos problemas y luego hacer un pull. Y si tienes una idea diferente me la haces saber.

[N3koSempai]

Hola. Creo que me comprendiste mal. en la carpeta de LAP en site-package solo necesito que se guarde repo . esta carpeta y su archivo solo tienen la relaciones entre el nombre de las librerías y su dirección en github, algo que el usuario no necesita ver y es mas bien de uso interno de LAP no tiene porque estar en el proyecto del usuario.

En cuanto a los módulos y la forma en la que se instalan. Se ve que es un problema algo complejo. Como tal las librerías puras de latino ( .lat sin llamadas a nada mas) no son un problema para manejarlas en jerarquía de archivo típica. o sea todo contenido dentro de la carpeta módulos con su incluir y exportar típico. pero claro una vez ya empiezan a llamar a librerías del sistema la cosa cambia.

Personalmente no me gusta para nada el uso de una variable de entorno llamada LATINO_LIB que ademas como comentas termina ocasionando problemas de permisos. Esta es mi incompleta propocision. las librerías compatibles con LAP tendrán dos archivos. 1- un zip como hasta ahora que contiene la librería. 2- un archivo de declaración de dependencias e información de la librería. issue #4 este segundo archivo tendrá una opción para indicar si la librería es pura o necesita algún tipo de ejecución adicional. aquí el desarrollador define que ejecutar. ejemplo un script en latino (de paso que esta instalado sea cual sea el so) y ese script hace las cuestiones que el desarrollador considere necesarias. ya sea compilar algo o elevar privilegio para alguna tarea. dado que este archivo es lo primero que se recibe el usuario puede ver que necesita esa librería antes de descargarla ya que puede estar declarado.

Resumiendo. LAP manejara solo una estructura de jerarquía de archivo dentro de la carpeta módulos. Esto hará que sea agnóstico de cualquier SO ya que son direcciones relativas. LAP leerá el archivo de config de la librería y ejecutara pasos adicionales definidos por el desarrollador previo consentimiento del usuario . Las configuraciones de variables de entorno diferentes para diferentes SO recaen en el desarrrollador (de la libreria a instalar) y de hay las acciones a tomar quitando a LAP estos problemas. La idea es que un usuario solo necesite dar acceso a LAP con privilegios en casos muy contados. Se me ocurre también que sea LAP quien identifique el SO y ejecute el script pertinente establecido por el desarrrolador de la libreria.

Probablemente muchas cosas no tome en cuenta o tengan errores , esto es solo una idea general para demostrar que quiero evitar espacios virtuales, variables de entorno que apuntan a zonas de alto privilegio o comportamientos diferentes según SO ( es por eso que LAP solo usa librerías built-in) al final esto debe reducir el mantenimiento muy agresivo de este programa.

déjame saber que problemas hay con esta idea (seguro que limita algo) o si tienes algún consejo para llevarla a cabo mejor. gracias por participar.