Come mantenere una versione a bassa dipendenza di un progetto?

Question

Come mantenere una versione a bassa dipendenza di un progetto?

#1 da (10 voti)
#2 da (2 voti)

5

Non sono così abile come la maggior parte delle persone che chiedono qui. Uso git per eseguire il backup del mio lavoro in un repository online, ma lo uso raramente in collaborazione e non conosco molto più delle funzioni di base.

Ho un po 'di codice (penso più come un branco di script, davvero) che uso per elaborare alcuni dati. Spesso, altre persone (anche un po 'tecnicamente qualificate) vogliono vederne alcune. Sfortunatamente, le dipendenze per eseguirlo includono ROOT con ganci Python 3 (si installa di default con gli hook Python 2 e nessuno sta per reinstallarsi ROOT per eseguire il mio codice) e una serie di altre librerie di considerevoli dimensioni. Il mio progetto è python 3 e quindi probabilmente non sarà in grado di utilizzare l'installazione ROOT della maggior parte delle persone.

Per rendere le cose più accessibili, ho un sottoinsieme di moduli che evita qualsiasi dipendenza più esoterica in un'altra cartella. Tuttavia, sospetto che esista un modo migliore per mantenere una versione a bassa dipendenza rispetto al codice di copia-incolla.

Ho letto questa domanda: Come mantenere versioni diverse e personalizzate dello stesso software per più clienti e sembra che potrebbe essere la giusta direzione. Tuttavia, ha detto che i rami dovrebbero contenere modifiche minime. Ho bisogno di una versione del progetto che contenga solo 1/3 dei file, con alcune modifiche minori in alcuni file (rimozione delle importazioni). Mi sembra molto diverso. Le filiali in un repository sono ancora il modo giusto per gestirle?

version-control python

posta Clumsy cat 14.11.2018 - 09:11

fonte

2 risposte

Leggi altre domande sui tag version-control python

Server separati rispetto alla macchina locale per build, rilascio di problemi, ecc. su progetto solo [chiuso] Qual è il modo preferito per proteggere la proprietà del proprio codice (ad esempio copyright, licenze, ecc.)

score 10 · Answer 1

La risposta a cui ti riferisci potrebbe essere la risposta accettata, ma non è la risposta più promossa. Citando l'eccellente risposta di Alb (enfasi mia):

Don't do this with SCM branches. Make the common code a separate project that produces a library or project skeleton artifact. Each customer project is a separate project which then depends on the common one as a dependency.

L'opzione migliore per te è quella di dare forma al tuo "branco di script". Qualsiasi funzione, classe, ecc. Che siano veramente identiche dovrebbe essere presa in considerazione in moduli indipendenti che possono essere importati e integrati dalle versioni separate. Non è necessario utilizzare un framework DI per ottenere il codice modulare.

Dovresti strutturare le versioni in cartelle separate con file requirements.txt unici per una facile creazione di virtualenv. Quindi mantieni aggiornate entrambe le versioni nello stesso ramo che continui a sviluppare.

Dovresti anche impostare test che convalidino le uscite delle varie versioni su piccoli esempi e bug segnalati per assicurarti che le tue modifiche future non interrompano la funzionalità esistente.

score 2 · Answer 2

Per quello che hai descritto probabilmente scriverei un semplice script "build", che

copia tutto il codice che vuoi distribuire in una cartella separata (e nient'altro)
se necessario, apporta le modifiche necessarie al codice in quella copia, per rimuovere le dipendenze non necessarie (come rimuovere alcune righe di "importazione").

Puoi scrivere lo script anche in Python, se vuoi.

Quindi, invece di copiare manualmente il codice che vuoi distribuire, automatizza questa attività. Questo non è un "trucco" o "trucco": generare diverse varianti di un software da una singola fonte è una tecnica di ingegneria del software standard.

Si può interpretare come un "processo di compilazione", con diverse configurazioni di build prodotte da un preprocessore, che è molto comune quando si usano linguaggi compilati come C.

Ovviamente, dovresti evitare di dover modificare troppi punti (se presenti) nel codice dal tuo script, altrimenti questo potrebbe diventare soggetto a errori. Idealmente, ci sono solo pochi file in cui è necessario importare i moduli ROOT e possono lasciarli fuori durante il processo di copia (ma se ciò non è possibile, basta togliere alcune linee di importazione specifiche non è davvero una scienza missilistica). Dovresti anche avere qualche convalida che la base di codice "parziale" generata funzionerà perfettamente e che non hai dimenticato di copiare alcuni file di codice importanti. Alcuni test automatici potrebbero essere utili per questo.