Extensión de paquetes a repositorios externos y control de versiones

[Víctor de Buen Remiro]

Actualmente el #Require sólo permite usar el repositorio oficial de TOL lo cual no permite el uso de paquetes privados dentro de una empresa o una organización cualquiera que quiera compartirla sólo de forma interna a la misma.

Por otra parte, si hay cambios en el desarrollo del paquete el usuario no se entera y no se puede beneficiar de las mejoras.

Además no es posible controlar qué versión del paquete se precisa en un proyecto. Esto último podría resolverse permitiendo la sintaxis opcional

//Carga exactamente la versión 1.1 del repositorio local
  #Require MyPkg.1.1

//Carga la última versión que haya en el repositorio local
  #Require MyPkg

Esto permitirá distinguir entre distintos archivos locales El nombre del paquete será la parte anterior al primer punto, por lo que sólo se podrá cargar una versión del mismo paquete en una sesión, ya que una vez cargado un NameBlock, las posteriores llamadas al #Require no hacen nada.
Todo este tipo de acciones requieren demasiada interactuación con el usuario para que se puedan controlar de forma automática por lo que quizás debería encomendarse su gestión al interfaz de TOLBase.

Si el paquete está localmente almacenado el #Require lo carga sin más, con lo que dicho sistema puede tomar el mando del control de versiones, dirección del repositorio y la actualización de los paquetes, sea esta automática o a petición del usuario.

Este sistema de gestión de paquetes, de ahora en adelante PkgGest, tendrá un menú con las siguientes opciones:

• New repository: permitirá al usuario dar de alta un repositorio como una dirección URL a un directorio con permiso de lectura en el que haya un fichero de entrada entries.tab que contenga un listado de los paquetes disponibles e una tabla con este aspecto:

PackageName	VersionNumber	LastUpdate
MyPkg	1.1	2010/02/12
MyPkg	1.2	2010/04/18
MyOtherPkg	1.1	2010/01/09

• Install package: te sacará primero un selector del repositorio y una vez elegido, uno o varios, saldrá otro selector múltiple con los paquetes disponibles. Se podrán elegir varios paquetes para ser instalados a la vez e incluso varias versiones de un mismo paquete. El sistema consultará la tabla entries.tab del repositorio correspondiente y de alguna forma gráficamente clara, se diferenciarán los paquetes según haya o no una copia en el repositorio local y según esté o no actualizada, para que el usuario sea consciente del estado de obsolescencia en el que se encuentra. Una vez aceptada la selección, se guardará una copia de seguridad de cada paquete local que ya existiera, y se descargarán los paquetes elegidos desde el repositorio, de forma que la siguiente llamada a #Require ya cargue el paquete recién actualizado sin tener que hacer nada de particular. Esto lo podrá hacer el usuario siempre que quiera. Habría que facilitar una forma sencilla de seleccionar todos los repositorios y todos los paquetes desactualizados o no descargados de los repositorios seleccionados, para no tener que pinchar de uno en uno.
• Automated upgrade: Aquí el usuario puede programar una actualización periódica de una selección de paquetes.