Non pensare troppo a Pip. Se la configurazione Setuptools funziona correttamente, è abbastanza facile caricare tutti e solo i file che si desidera effettivamente su PyPI ( a quel punto gli utenti finali saranno in grado di installarlo con Pip; gli sviluppatori cloneranno il tuo repository git poiché hanno bisogno di cronologia per cose come git bisect per funzionare e Pip non fornisce la cronologia git).
Preoccupati invece di come verrà presentato il tuo progetto. Un layout comune è simile a questo:
Root directory
|
+- name-of-your-project/
| |
| +- __init__.py
| |
| +- other modules and packages...
|
+- name-of-forked-dependency/
| |
| +- __init__.py
| |
| +- other modules and packages...
|
+- setup.py
|
+- Other stuff...?
"Altre cose" potrebbero includere documentazione, test unitari e altri materiali misti che non desideri distribuire insieme al tuo codice. È anche piuttosto comune mettere un file requirements.txt qui come suggerimento per gli sviluppatori che dovrebbero installare determinati pacchetti per lavorare sul tuo progetto. Nota che Setuptools è abbastanza intelligente da includere alcuni file ma non altri, quindi puoi semplicemente mettere la maggior parte di questi file direttamente accanto al codice sorgente, se preferisci.
La prossima domanda è come si ottiene il repository in questo modo preservando la cronologia della dipendenza forked. Supponendo che l'altro progetto segua lo standard Python di mantenere il proprio codice in una directory chiamata dopo il suo pacchetto radice, hai due opzioni:
- Se il tuo codice esiste già e ha una cronologia , potresti voler creare un repository git con due radici. Una radice sarà il commit iniziale del tuo codice e l'altra sarà il commit iniziale del codice che stai biforcando. Per quanto posso dire, sembra fattibile semplicemente facendo un
git remote add e poi un git fetch sul nuovo telecomando. Successivamente, probabilmente vuoi unire i rami insieme a git merge , a quel punto avrai un solo ramo principale con tutta la cronologia da entrambi i repository.
- Se il tuo codice non ha ancora la cronologia , questo è ancora più semplice: basta clonare il repository da biforcarsi, modificare
origin in qualcosa di sensato come un repository GitHub di nuova emissione, spingere e iniziare lo sviluppo.
Quanto sopra presuppone che si desideri distribuire la copia del codice a forcella come unità accanto al proprio progetto. Potrebbe essere più sensato distribuirli separatamente e elencare la forcella come dipendenza del codice nella configurazione di Setuptools. In questo modo, puoi mantenere due repository separati per ognuno di essi e fornire un pacchetto separato su PyPI per le persone che vogliono solo lavorare con il tuo codice biforcato. Gli sviluppatori che vogliono contribuire a entrambi i repository dovranno fare un po 'più di lavoro, tuttavia, quindi dovrai valutare te stesso i vantaggi e gli svantaggi.
Per completezza, dovresti anche essere a conoscenza dello strumento Virtualenv , che ha un valore inestimabile per la gestione di situazioni di dipendenza complesse come come il tuo, ed è anche abbastanza adatto anche per le distribuzioni più semplici.