NotesPrincipe général
Le cadre général est de faire en sorte que la commande principale soit la plus restreinte possible, mais que l’on puisse ajouter de nouvelles fonctionnalités à l’infini dans des extensions (placées par exemple dans des plugins).
Le but est évidemment de faciliter la maintenance du code, d’avoir chaque grande fonctionnalité dans un fichier à part, et de pouvoir facilement distribuer des extensions aussi bien générales que dédiées à un plugin précis.
Noyau
Le noyau de la commande serait un unique fichier exécutable, que l’on pourrait donc aussi installer en global dans un système (dans /usr/bin quoi).
Fonctionnalité minimale :
- gestion des arguments passés en paramètre
- installation de SPIP en plusieurs version (uniquement par SVN ? c’est le plus simple à gérer en tout cas)
- installation de dossiers en plus directement (
plugins/,lib/) - gestion des bons droits de dossiers pour les cas simples (777 en environnement local de développement, par exemple)
- détection que la commande est lancée dans un dossier qui contient un SPIP installé
- intégration du PATH de SPIP et recherche d’extension dedans, selon une convention, dans un dossier déterminé
- lancement d’une extension en lui refilant les arguments éventuels
Extension
Pour plus de simplicité, une extension serait obligatoirement développée en PHP. Cela permet en effet de déléguer au noyau la gestion de tout ce qui est commun (notamment le scannage des arguments), et de ne faire qu’une inclusion avec un appel de fonction pour les extensions.
Une extension serait donc constituée au minimum d’un fichier normé dans le bon dossier, avec dedans une fonction homonyme (selon charger_fonction() à priori ?). Elle peut ensuite elle-même avoir besoin d’autres fichiers, que ce soit en appelant des commandes du shell (svn par exemple, ou chmod), ou des librairies et fonctions de SPIP.
Liens utiles
Le composant indépendant de création d’appli console de symfony
L’outil de commande pour Drupal