Quali sono i modi più efficaci per gestire la decomposizione nelle dipendenze della piattaforma?

Question

Quali sono i modi più efficaci per gestire la decomposizione nelle dipendenze della piattaforma?

#1 da (2 voti)

1

Ho un paio di siti Pinax inattivi con versioni diverse (0.9.xe 0.7.x). Entrambi hanno iniziato con due caratteristiche comuni:

Mentre la versione di Pinax era la più recente ad avere un progetto di avviamento (non vuoto) social , erano entrambi relativamente vecchi; e:
L'installazione si basava sull'acquisizione di alcune dipendenze estremamente rare e difficili.

Nel guardare questo, sembra esserci un tema di crescente fragilità. Le dipendenze sembrano costituire singoli punti di errore, e la tendenza è di avere sempre più di loro.

Qualche suggerimento su come far fronte a questo, sopra la creazione di un virtualenv mentre è ancora possibile? Quali opzioni dovrei prendere in considerazione se voglio minimizzare l'aggiunta di dipendenze (possibilmente effimere)? Ci sono modi per stimare quanto è effimera una data dipendenza?

Probabilmente con un nastro adesivo adeguato, potrei disporre ad esempio di una galleria di virtualenvs e assicurarmi che ogni singola versione di ogni singola dipendenza sia disponibile in formato sorgente e installato.

Sto cercando di creare tutto un progetto autonomo con le proprie app "roll your own", non perché ritengo che questo sia desiderabile o Pythonic in sé, ma per mettere in quarantena la maggior parte o tutti i singoli punti di errore al mio proprio codice, che idealmente dovrebbe funzionare e distribuibile dopo aver scaricato Python, Django (se necessario) e il mio progetto da solo.

python dependencies django

posta JonathanHayward 13.01.2018 - 13:58

fonte

1 risposta

Leggi altre domande sui tag python dependencies django

Automatizzare le chiamate all'API REST Event Sourcing e cross Aggregate validation

score 2 · Answer 1

La gestione delle dipendenze comporta la gestione dei rischi, che può essere vista come un argomento sia a favore che contro le dipendenze.

Quando ho una dipendenza, i rischi sono i seguenti:

la dipendenza potrebbe non essere più disponibile in futuro (* cough * leftpad)
la dipendenza può evolvere in modi incompatibili
la dipendenza potrebbe risultare insufficientemente flessibile dopo che sono già stato bloccato per utilizzarlo
la dipendenza potrebbe contenere bug e vulnerabilità

Tuttavia, quando non uso una dipendenza e scrivo il mio codice, il rischio è questo:

Potrei dedicare uno sforzo sproporzionato a un sostituto
il mio codice potrebbe contenere più bug perché è usato meno
il mio codice potrebbe contenere gravi problemi di sicurezza perché ho meno familiarità con il dominio problematico e i concetti di sicurezza
il mio codice potrebbe trasformarsi in debito tecnico nel corso degli anni

Qualsiasi tipo di codice è una responsabilità, indipendentemente da chi lo scrive.

Molti dei rischi implicati dall'uso delle dipendenze possono essere mitigati, a seconda del gestore dei pacchetti.

Disponibilità e compatibilità sono abbastanza facili da garantire, bloccando una versione o un intervallo di versioni e ospitando la tua copia. Ogni gestore di pacchetti ti consente di fornire il tuo mirror per i pacchetti che utilizzi. Questo può essere semplice come una directory locale piena di tarball che può essere facilmente salvata. Ci possono anche essere strumenti che possono raggruppare versioni aggiunte di tutte le dipendenze in un archivio facilmente distribuibile. Altri gestori di pacchetti potrebbero richiedere l'hosting di un server, che potrebbe rendere uno specchio meno attraente. Si noti che il mirror deve essere aggiornato un po 'per trarre vantaggio dalle patch di sicurezza upstream.

Una dipendenza "rara e difficile" non dovrebbe esistere. Se è possibile ospitare una dipendenza da soli, non è raro e se può essere installato tramite un gestore di pacchetti non è difficile. Se dipendi da un servizio come un database, allora è più difficile perché non solo deve essere installato, ma deve anche essere in esecuzione. Potrebbe essere utile specificare la configurazione con gli strumenti di gestione della configurazione o creando un'immagine del contenitore.

Una nota sull'installazione dai repository di controllo delle versioni, ad es. da GitHub: il repository di qualcun altro non è una dipendenza saggia. Invece, controlla sempre una revisione specifica e indica sempre una forcella sotto il tuo controllo.

Quanto dovresti essere paranoico riguardo alle dipendenze dipende dalla natura del progetto. Per i miei progetti open source non applico nessuna di queste misure di attenuazione. Non ne vale la pena, oltre a richiedere una versione minima. Per il mio lavoro professionale, ho imparato a valutare dipendenze più controllate.