unattended installation

[simevo]

Sarebbe utile avere una modalità di installazione non interattiva per il pacchetto spid-php.

L'unattended installation sarebbe opzionale ed alternativa a rispondere alle 7-8 domande poste dal setup script.

Idealmente qualunque cosa di canonico nel mondo php / composer, a me viene in mente un file config.yaml che se lo trova nella root vi legge le opzioni e non pone nessuna domanda interattiva (assumendo i default per le opzioni mancanti).

Ciò sarebbe utile se questo pacchetto dovesse essere richiamato dal composer install di un progetto di livello superiore che lo integra con altri (ad esempio il futuro spid-drupal).

[simevo]

vorrei affrontare questa issue come segue:

1. definire una funzione privata in Setup.php: Setup::setup_($curDir, $wwwDir, $serviceName, $entityID, $acsIndex, $addTestIDP, $localTestIDP) { ... dove muoverei tutto quello che adesso c'è dalla linea 52 in poi.

2. in Setup::setup, se esiste un file config.yml prova a leggere le 7 impostazioni, se non esiste il file le legge da stdin

3. se alcune opzioni non sono settate, applica i valori di difetto (sono le istruzioni come if($curDir==null || $curDir=="") $curDir = $_curDir;

Però vorrei fare tutto ciò a valle di #7, quindi sto aspettando di vedere che fine fa la PR ...

[damikael]

Ok. Inoltre:

2. in Setup::setup, se esiste un file config.yml prova a leggere le 7 impostazioni, se non esiste il file le legge da stdin e scrive il file config.yml con le configurazioni inserite dall'utente.

3. ...

4. in composer.json definire lo script "update": setup\Setup:update che provvede ad aggiornare i metadata degli IDP (compreso local test IDP). Conviene quindi isolare in altra funzione privata la parte di aggiornamento metadata.

[simevo]

Sto impostando la fix qui: https://github.com/simevo/spid-php/tree/feature/issue-9-unattended-installation, è finita tranne il punto 4. Commenti sono benvenuti !

Per il punto 4, adesso Setup::setup è associata all'evento post-update-cmd, si tratterebbe di associarla al post-install-cmd ed associare Setup::update a post-update-cmd?

[damikael]

È corretto che il setup sia eseguito sull'evento post-update-cmd in quanto
post-update-cmd: occurs after the update command has been executed, or after the install command has been executed without a lock file present. (https://getcomposer.org/doc/articles/scripts.md)

Per il punto 4, possiamo definire uno script update-metadata associato ad una funzione Setup::updateMetadata.

   "scripts": {
        "post-update-cmd": [
            "setup\\Setup::setup"
        ],
        "uninstall": [
            "setup\\Setup::remove"
        ],
        "update-metadata": [
            "setup\\Setup::updateMetadata"
        ]
    },