Quanto è sicuro affidarsi alle librerie Python di terze parti in un prodotto di produzione?

Question

Quanto è sicuro affidarsi alle librerie Python di terze parti in un prodotto di produzione?

#1 da (6 voti)

2

Sono nuovo di Python e provengo dal mondo di PHP di scrittura-tutto-te (almeno questo è il modo in cui mi sono sempre avvicinato).

Sto usando Flask, WTForms, Jinja2, e ho appena scoperto Flask-Login che voglio usare. La mia domanda riguarda l'affidabilità dell'utilizzo di librerie di terze parti per le funzionalità di base in un progetto che è previsto in giro da diversi anni.

Ho installato queste librerie (tramite pip) in un ambiente virtualenv. Cosa succede se queste librerie smettono di essere distribuite? Devo eseguire il backup di queste librerie (sono uova)? Posso memorizzare queste librerie nel mio stesso progetto, invece di affidarmi a pip per installarle in un virtualenv? E dovrei conservarli separatamente?

Sono preoccupato che mi affidi a una libreria per le funzionalità di base, e poi un giorno scaricherò una versione incompatibile tramite pip, altrimenti l'autore o il maintainer smetteranno di distribuirlo e non sarà più disponibile .

Come posso proteggermi da questo e garantire che le librerie di terze parti che utilizzo nei miei progetti siano sempre disponibili così come sono adesso?

python flask

posta skyler 03.09.2012 - 21:12

fonte

1 risposta

Leggi altre domande sui tag python flask

Verifica della domanda dei requisiti Buone risorse per l'apprendimento della ricorsione [duplicato]

score 6 · Accepted Answer

Ho implementato applicazioni web Python per anni e questo ha raramente stato un problema.

Nota che ciò che descrivi e temi potrebbero accadere a qualsiasi progetto open source, incluso in PHP, Apache o anche Linux. Cosa succede se un progetto OSS diventa AWOL? Se c'è stato un numero qualsiasi di persone che fanno affidamento su di esso, i backup delle distribuzioni possono sempre essere trovati da qualche parte su Internet.

Si noti inoltre che se si utilizza un metodo di distribuzione affidabile e riproducibile, in cui si vincolano le versioni di dipendenza a una sola versione, non si dovrebbe mai incorrere nello scenario di "versione incompatibile" accidentale che si descrive. pip ha il comando freeze per darti un elenco riutilizzabile di versioni, per esempio.

L'utilizzo di uno strumento come buildout ti offre un'altra strada per creare una configurazione di distribuzione completamente riproducibile e non solo puoi appuntare la tua libreria versioni con esso, puoi istruire buildout per non installare mai un pacchetto python a meno che non hai configurato una versione esplicita per quel pacchetto ( allow-picked-versions = false ). Le cache di buildout hanno scaricato i file di distribuzione del pacchetto, dandomi un facile accesso a quei backup che ho menzionato prima.

Infine, ma non meno importante, crei automaticamente tale cache di backup con un mirror PyPI locale sufficientemente intelligente come collective.eggproxy . Sia PyPI che buildout possono essere istruiti a utilizzare il mirror al posto del repository PyPI centrale e creerà una cache di pacchetti man mano che procederai, completamente automatico.