Come posso gestire le versioni di sviluppo dei pacchetti Python senza fare affidamento su SCM?

Question

Un problema che si presenta durante lo sviluppo di Pinax riguarda le versioni di sviluppo di app esterne. Sto cercando di trovare una soluzione che non implichi l'introduzione dei sistemi di controllo delle versioni. La ragione è che preferirei non dover installare tutti i possibili sistemi di controllo delle versioni sul mio sistema (o forzarli con i contributori) e affrontare i problemi che potrebbero sorgere durante la creazione dell'ambiente.

prendere questa situazione (sapere come funziona Pinax sarà utile alla comprensione):

Stiamo iniziando lo sviluppo su una nuova versione di Pinax. La versione precedente ha un file dei requisiti di pip con le versioni esplicite impostate. Arriva un errore per un'app esterna che vorremmo risolvere. Per ottenere quella correzione di bug in Pinax, il processo attuale consiste semplicemente nel fare una versione minore dell'app, assumendo che abbiamo il controllo dell'app. Le app che non abbiamo il controllo ci occupano solo del ciclo di rilascio dell'autore dell'applicazione o le costringono a realizzare rilasci ;-) Non mi piace troppo realizzare costantemente versioni minori per correzioni di bug come in alcuni casi mi piacerebbe essere lavorando anche su nuove funzionalità per le app. Naturalmente ramificando la versione precedente è ciò che facciamo e poi facciamo i backport di cui abbiamo bisogno.

Mi piacerebbe sentire qualche idea al riguardo.

Answer 1

Intendevo dire che la soluzione che avevo preso in considerazione prima di chiedere era di montare un PyPI Pinax e creare versioni di sviluppo su di esso. Potremmo organizzare un'istanza di un vescovo. Stiamo già utilizzando i collegamenti di pipe di pf per puntare su pypi.pinaxproject.com per i pacchetti che abbiamo dovuto rilasciare noi stessi.

Answer 2

Si può gestire questo utilizzando l'identificatore di versione "== dev"? Se la pagina della distribuzione su PyPI include un link a un .tgz della versione corrente del dev (come github e bitbucket forniscono automaticamente) e aggiungi "# egg = nome_progetto-dev" al link, sia easy_install che pip lo useranno .tgz se è richiesto == dev.

Questo non ti permette di aggiungere qualcosa di più specifico di "punta/testa più recente", ma in molti casi che potrebbe essere abbastanza buono?

Answer 3

La maggior parte dei distributori open source (i Debians, Ubuntu, MacPorts e altri) utilizzano una sorta di meccanismo di gestione delle patch. Quindi qualcosa di simile: importa il codice sorgente di base per ogni pacchetto come rilasciato, come una sfera tar, o come uno snapshot SCM. Quindi gestisci tutte le modifiche necessarie su di esso utilizzando un gestore patch, ad esempio quilt o Mercurial's Queues. Quindi raggruppa ciascun pacchetto esterno con tutte le patch applicate in un formato coerente. Oppure avere URL per i pacchetti e gli URL di base per le singole patch e averli applicati durante l'installazione. Questo è essenzialmente ciò che fa MacPorts.

MODIFICA: Per fare un ulteriore passo avanti, è quindi possibile controllare la versione del set di patch su tutti i pacchetti esterni e rendere quello disponibile come unità. Questo è abbastanza facile da fare con Mercurial Queues. Quindi hai semplificato il problema semplicemente pubblicando un set di patch utilizzando un sistema SCM, con le patch applicate localmente come sopra o disponibili per gli sviluppatori per estrarre e applicare alle loro copie dei pacchetti di rilascio di base.

Answer 4

EDIT: Non sono sicuro di aver letto correttamente la domanda in modo che le seguenti domande non rispondano direttamente alla domanda.

Qualcosa che ho preso in considerazione, ma che non ho testato, utilizza la funzione di blocco del freeze di pip. Forse usare questo e distribuire il pacchetto con Pinax funzionerebbe? La mia unica preoccupazione sarebbe come vengono gestiti i diversi SO. Ad esempio, non ho mai usato pip su Windows, quindi non saprei come un bundle potrebbe interagire lì.

L'idea completa che spero di provare è la creazione di uno script di finitrice che controlli la gestione dei pacchetti, semplificando agli utenti l'aggiornamento alle versioni più recenti. Ciò richiederebbe comunque un po 'di impalcatura.

Un'altra opzione potrebbe consistere nel tenere un mirror delle app che non controlli, in un vcs coerente e quindi distribuire le versioni di mirroring. Ciò toglierebbe la necessità a "tutti" di avere molti programmi diversi installati.

A parte questo, sembra che l'unica soluzione reale sia ciò che voi ragazzi state facendo, non c'è un modo semplice che ho potuto trovare.