Come spesso dipende . Ho dovuto prendere questo tipo di decisione diverse volte in passato, quindi cercherò di fornire alcune linee guida generali da questa esperienza.
In primo luogo, questo ha senso solo dove un programma offre una CLI e un'interfaccia di libreria. Se l'unica interfaccia "ufficiale" per un programma è la CLI, probabilmente è meglio usarla. Tuttavia, per i casi in cui entrambi i tipi di interfacce sono disponibili, dipende da diverse cose. Alcuni esempi popolari, fuori di testa:
Hai già menzionato alcuni pro e contro, qui ci sono alcuni aspetti aggiuntivi da considerare:
-
La qualità delle API (CLI vs lib API)
-
esecuzione "in-process" (lib) rispetto all'esecuzione "out-of-process" (CLI)
-
Il tipo di comunicazione richiesta tra l'applicazione che utilizza e il programma / libreria chiamato.
-
problemi di licenza (ad esempio, se la libreria / programma che si desidera utilizzare è in GPL)
-
testabilità
-
Altri fattori come il codice già esistente, l'ambiente di destinazione, i problemi relativi alla sicurezza, i problemi relativi al know-how e così via.
Per alcuni di questi programmi / librerie, l'API della libreria e la CLI non offrono esattamente lo stesso set di funzionalità, quindi è molto probabilmente la prima cosa da cercare.
IMHO le principali differenze tra un programma CLI e una lib sono il risultato della comunicazione out-of-process / in-process. Ciò impone un approccio di comunicazione molto diverso tra il tuo programma e il lib / program, e anche una diversa gestione degli errori. "out-of-process" ha il vantaggio di far funzionare il programma chiamato in un isolamento migliore e offre la possibilità di gestire i crash del programma in modo più aggraziato. Nel caso del software GPL, ha anche il vantaggio di evitare gli aspetti virali di GPL.
Come già accennato, l'esecuzione di un processo separato sarà in genere più lenta rispetto alla chiamata diretta a una libreria. Tuttavia, se questo è veramente significativo per un caso d'uso specifico dipende, molto, dal caso d'uso specifico. In alcuni casi, l'esecuzione di out-of-process può rendere le cose più veloci più runner, a causa dell'esecuzione parallela implicita.
Le opzioni di comunicazione con un programma CLI sono in genere molto più limitate, specialmente quando i parametri della riga di comando (e forse alcuni file) sono l'unico modo di alimentare l'input nel programma e un codice di ritorno e file di output sono l'unico modo di ottenere uscita. Ciò rende l'utilizzo di una libreria spesso obbligatorio quando si ha bisogno di un protocollo di comunicazione più complesso. Se il caso d'uso richiede che funzioni con strutture dati restituite da chiamate lib e le restituisca ad altre funzioni della libreria, o se il caso d'uso richiede callback, una CLI non ha molto senso. Ad esempio, libxslt / libsml ti dà la possibilità di accedere all'intero DOM di un file XML e lavorare con esso nel tuo programma. Non ho idea di come dovrebbe essere fatto in modo comparabile usando semplicemente il client della riga di comando xsltproc. Tuttavia, se è necessario eseguire uno script xslt su un file xml di input e ottenere il file risultante per un'ulteriore elaborazione, utilizzare xsltproc può essere sufficiente o addirittura preferibile.
Informazioni sulla testabilità: con ImageMagick ho reso l'esperienza che potrebbe essere più semplice testare singolarmente i comandi della CLI e quindi lasciare che un programma chiami la CLI con esattamente gli stessi parametri. D'altra parte, l'utilizzo di un client di database CLI per testare alcune SQL e quindi l'utilizzo di tali SQL direttamente in combinazione con un'API DB in forma di lib mi ha spesso servito anche molto bene.
Sul tuo "utente potrebbe avere una versione diversa dell'argomento" installato nella CLI: beh, questo potrebbe anche essere il caso quando usi una lib, immagino? Per le librerie libere, l'ambiente può fornire il controllo automatico delle versioni, tuttavia, molti programmi CLI consentono di chiedere loro anche un numero di versione, quindi offre almeno un'opportunità per effettuare alcuni controlli di integrità in precedenza.
Quindi, in breve, non esiste una soluzione generale "giusta" o "sbagliata" o "migliore" qui, è necessario esaminare il singolo caso e prendere una decisione per il caso specifico.