2010-11-01 6 views
5

Attualmente sto realizzando alcuni progetti in python e sto cercando di capire come utilizzare le mie versioni dei pacchetti open source esistenti.Uso di pacchetti personalizzati sul mio progetto python

Per esempio, sto usando tipfy con zc.buildout, e ho aggiunto nel pacchetto 'paypal'. Sfortunatamente non ha una funzione di cui ho bisogno, quindi l'ho bifrata su github e ho aggiunto la funzione. Invierò ai manutentori dei pacchetti originali una richiesta di pull, ma se accetteranno o meno le mie aggiunte, vorrei usare la mia versione del pacchetto e mantenere la comodità di avere zc.buildout a gestire le mie dipendenze. Come faccio a fare questo?

Devo caricare il mio take sulla libreria su PyPI e lo prefisso con il mio nome? Non inquinerebbe inutilmente l'indice?

Oppure devo creare e gestire il mio repository e il mio repository? Dove trovo il formato per questo? Ed è contrario ai termini delle licenze OSS ospitare il mio repository con pacchetti modificati con gli stessi nomi? (Preferisco non modificare tutti i file del progetto con nuovi spazi dei nomi)

Sono sicuro che questo problema si presenta molto, e non solo con Python. Posso vedere questo anche con Maven e SBT ... cosa fanno di solito le persone quando vogliono usare le loro versioni di pacchetti popolari?

risposta

5

Ci sono due modi per procedere. Io uso entrambi, a seconda del contesto buildout viene utilizzato per:

  1. Usa mr.developer per includere i pacchetti da un sistema di controllo di versione (mr.developer supporta una vasta gamma di sistemi, compresa GIT). Lo uso durante lo sviluppo.

  2. Creare un repository di pacchetti privati. Un semplice elenco di directory in Apache è sufficiente. Aggiungere l'URL al repository privato come voce find-links:

    [buildout] 
    ... 
    find-links = 
        ... 
        http://username:[email protected]/projectname 
    

    In questo esempio ho incluso anche un nome utente e una password (buildout allora autenticherà) e un percorso sul server che è progetto specifico. Ovviamente puoi anche creare un unico repository privato per tutti i tuoi progetti.

    In questo repository o si mettono uova complete, o solo un tarball del pacchetto. I repository denominati in find-links vengono ricercati prima di PyPI.

    Io uso questo metodo per i buildout di distribuzione. In questo modo il software utilizzerà i pacchetti rilasciati, il che rende la gestione delle versioni molto più chiara e semplice.

Ospitare le proprie forcelle di pacchetti OSS è perfettamente a posto! Questa è una delle libertà che ottieni quando usi OSS. Tieni presente che quando forzi il codice GPL in questo modo e lo stai distribuendo a una terza parte, devi rendere disponibili le modifiche. Un repository di pacchetti è un modo per conformarsi a questo.

+0

Grazie ... andrà con questo. Vedo che è un modo davvero utile per mantenere i deps su più progetti. –

+0

Non è opportuno avere username e password nella configurazione di buildout. È meglio mettere quelli in .pypirc: vedere https://stackoverflow.com/questions/37323392/how-to-safely-basic-auth-to-private-pypi-with-zc-buildout – Petri

0

Eventuali percorsi inseriti in dependency_links in setup.py del progetto verranno cercati per primi. Quindi basta rilasciare il pacchetto in un percorso e impostare dependency_links su quel percorso.

local_packages = ['file:///path/to/packages'] 

setup(
... 
dependency_links=local_packages, 
...) 

Setuptool documenti coprono un po 'di più su come funziona il tutto, ma questo è davvero tutto quello che c'è ad esso.

Modifica: zc.buildout utilizza il file setuptools dependency_links var per impostazione predefinita. If you want to turn it off.

+0

Provi questo .. e quello che deve essere nella cartella è il tar.gz da 'sdist', giusto? –

+0

buildout offre opzioni molto migliori per gestirlo. Non c'è bisogno di perfezionare i pacchetti Python con la configurazione di distribuzione! –

+0

Penso che il buildout stia semplicemente mascherando questo meccanismo piuttosto che duplicandolo. La tua risposta all'uso dei link di ricerca sembra molto simile. Inoltre, non vedo nulla di sbagliato nelle configurazioni di distribuzione. Ogni pacchetto pypi ne ha uno. – dcolish

2

Per mantenere il tuo mal di testa sotto controllo, ti consiglio davvero di abbinare tutti questi codici personalizzati con il tuo pacchetto. Supponi di aver fatto un fork di qualche package. Fintanto che la sua licenza lo consente, accorperei semplicemente la versione modificata di package con il mio codice, come se fosse solo un'altra directory. È possibile posizionarlo localmente sotto package in modo che sia facilmente reperibile. Una volta che gli sviluppatori di package risolvono ciò di cui hai bisogno, rimuovi questa directory e rendila ancora una dipendenza da un pacchetto online.

Un ulteriore vantaggio di questo approccio è rendere la distribuzione agli utenti/clienti più semplice.

+0

Utilizzerò 'pacchetto' su più progetti ... davvero non voglio mantenere così tante copie di esso, specialmente quando posso averlo risolto come dipendenza. –

1

È passato un po 'di tempo da quando ho utilizzato buildout, ma se ricordo male, esiste una ricetta pip che consente di utilizzare i file dei requisiti di pip. È possibile creare un file dei requisiti che contiene qualcosa di simile:

-e git+http://<github url> 

Che verificherà il pacchetto in locale durante l'installazione.

+0

Questo è interessante .. . Verificherò –

0

È possibile caricare il proprio Take nella libreria su PyPI e prefisso con il mio nome?

No.

Non sarebbe inutilmente inquinare l'indice?

Ovviamente. (Inoltre, si presume che la propria estensione sia effettivamente utile per gli altri.Infatti, la propria estensione potrebbe indicare una mancata comprensione del pacchetto.)

oppure Realizzo e gestisco il mio repository e il mio repository personale?

Mai. È completamente sciocco. Hai il pacchetto modificato. Non hai bisogno di un repository a meno che non hai intenzione di completare contro PyPI. Potresti provare, ma perché preoccuparsi?


Ecco cosa si fa.

estendono

Si può facilmente estendere un dato pacchetto senza modificare o generando.

my_paypal.py

from paypal import * 

class MyFancyExtension(SomeExistingClass): 
    def override(self, ...) 

def my_other_extension(...): 
    this() 
    that() 

E 'abbastanza facile. Spesso è meglio che biforcarsi perché preservi il pacchetto originale non toccato dalle tue estensioni.

+0

Potrei farlo, ma voglio migliorare la libreria stessa e apportare modifiche a monte. Lo sto anche utilizzando come dipendenza per molti dei miei progetti. Sulla base di ciò potrebbe essere meglio ospitare un repository privato e ricadere sul main quando si raggiunge. –

+0

Si noti che esistono ottimi motivi per avere un server PyPI personalizzato ("indice e repo del pacchetto"). – Petri

0

Ha perfettamente senso avere il proprio server PyPI personalizzato per i propri pacchetti proprietari, privati, a forcella o di sviluppo.

Ad esempio pypiserver è leggero e facile da configurare.