2012-09-03 13 views
9

Sto sviluppando un pacchetto - myvendor/mylib - che ho intenzione di distribuire utilizzando Composer, probabilmente tramite Packagist. Questo pacchetto contiene, tra le altre cose, uno script PHP da riga di comando bin/console.php che vorrei mettere a disposizione dei progetti, ad esempio myvendor/mymain, che importa il pacchetto mylib.Lo script nella dipendenza ha bisogno del percorso per il caricatore automatico Composer

Sono consapevole che posso specificare nel pacchetto mylib un ambiente config in composer.json con una serie di bidoni per importare:

{ 
    "name": "myvendor/mylib", 
    "config" : { 
     "bin" : ["bin/console.php"] 
    } 
} 

Quando il progetto mymain non un compositore installazione/aggiornamento, allora questo mylib/bin/console.php è link simbolico come mymain/bin/console.php Inoltre, sono consapevole che il progetto mymain può specificare - nel suo composer.json - dove ha vuole bidoni di dipendenza da creare collegamenti simbolici:

{ 
    "name": "myvendor/mymain", 
    "config": { 
     "bin-dir": "scripts" 
    } 
} 

In questo caso, lo script della console viene quindi simulato come scripts/console.php.

Questo funziona benissimo - ed è bello come tutti gli altri, tra l'altro. ;-)

Tuttavia, lo script bin/console.php deve includere lo vendor/autoloader.php generato dal compositore. Quando si sviluppa mylib in isolamento, lo script bin/console.php conosce la propria posizione relativa a vendor/autoloader.php, in modo che possa includerlo facilmente. Ma una volta che viene importato come dipendenza in un altro progetto - myvendor/mymain, in questo caso - allora c'è solo lo script mymain/vendor/autoloader.php. In linea di principio, lo script della console non può sapere dove risiede relativamente a quello script del caricatore automatico.

Compositore fornisce una variabile di ambiente - accessibile allo script della console - che consente allo script di individuare lo script vendor/autoloader.php corretto?

BTW: Io sono a conoscenza del Composer CLI environment variable, quindi immagino che potrei farne un requisito che il progetto di importazione - mymain - definire la var COMPOSER_VENDOR_DIR (e l'esportazione!). Quindi lo script della mia console può usarlo per trovare il caricatore automatico del progetto. Ma che sembra potenzialmente problematico in che:

  1. Vogliamo l'impostazione da applicare solo ai questo progetto, ma una var guscio (e l'esportazione) si applicherebbe a tutti i progetti a cui si accede da quella sessione di shell. Sembra presuntuoso della mia piccola dipendenza - myvendor/mylib - imporlo a un progetto di importazione.

  2. In linea di principio, la dipendenza stessa - myvendor/mylib - dovrebbe essere in grado di trovare ciò di cui ha bisogno. Non sembra giusto mettere l'onere sull'importatore.

WDYT? Grazie in anticipo. Idee ben accette

risposta

3

Un approccio (che è venuto fuori di discussioni con @igorw su IRC freenode #composer che sto parafrasando e su cui mi sto un po 'in espansione) è di lasciare che lo script bin console.php iterare il file system, a partire dal __DIR__, alla ricerca di la presenza di autoload.php.

+2

Non è necessario per scorrere davvero, si può solo guardare due dirs fino dal momento che sarebbe partita // – Seldaek

+0

@Seldaek: Giusto, ho finalmente capito il campione da [jsonlint] (https: // github.com/Seldaek/jsonlint/blob/master/bin/jsonlint) e implementato in questo modo. Grazie mille! –

+0

Sembra che le persone abbiano ancora problemi con questo (io!) Trovato una risposta qui: http://stackoverflow.com/questions/35271282/how-can-i-provide-a-script-for-php-cli-via -composer-as-alone-e-come-Depen – VladFr

Problemi correlati