Italy mailing list archives
italy@odoo-community.org
Browse archives
Problema moduli oca e versioni manifest
by
TAKOBI s.r.l., Lorenzo Battistini.
Vi inoltro questa discussione, per condividere informazioni che ritengo utili.
--
---------- Forwarded message ---------
Il problema sorge, chiaramente, laddove tra le dipendenze del modulo che sto andando ad installare (forzandone la versione) non vengono specificate versioni "dev".
Lo so, infatti sto consigliando di specificare la versione per tutti i moduli che vi servono.
E' lo stesso motivo per cui odoo ha il suo requirements.txt: bisogna essere sicuri di avere i pacchetti nelle versioni che funzionano col nostro software.
Vi mando l'esempio un pezzo di requirements.txt che uso in una installazione 12:
odoo12-addon-l10n-it-account==12.0.1.0.0.99.dev5
odoo12-addon-date-range==12.0.1.0.0.99.dev4
odoo12-addon-account-tax-balance==12.0.1.0.0.99.dev3
odoo12-addon-account-fiscal-year==12.0.1.0.0.99.dev1
odoo12-addon-l10n-it-ipa==12.0.1.0.0.99.dev3
odoo12-addon-l10n-it-fiscalcode==12.0.1.0.0.99.dev3
odoo12-addon-l10n-it-rea==12.0.1.0.1.99.dev1
odoo12-addon-l10n-it-account-tax-kind==12.0.1.0.0.99.dev3
odoo12-addon-l10n-it-esigibilita-iva==12.0.1.0.0.99.dev2
odoo12-addon-l10n-it-fiscal-document-type==12.0.1.1.0.99.dev1
odoo12-addon-l10n-it-fiscal-payment-term==12.0.1.0.0.99.dev4
odoo12-addon-account-due-list==12.0.1.0.0.99.dev1
odoo12-addon-l10n-it-causali-pagamento==12.0.1.0.0.99.dev3
odoo12-addon-l10n-it-split-payment==12.0.1.0.0.99.dev5
odoo12-addon-l10n-it-withholding-tax==12.0.1.0.0.99.dev10
odoo12-addon-partner-firstname==12.0.1.0.0.99.dev1
odoo12-addon-l10n-it-withholding-tax-causali==12.0.1.0.0.99.dev3
odoo12-addon-l10n-it-fatturapa==12.0.1.2.0
odoo12-addon-l10n-it-fatturapa-in==12.0.1.1.0.99.dev1
odoo12-addon-l10n-it-fatturapa-out==12.0.1.0.1.99.dev13
odoo12-addon-l10n-it-sdi-channel==12.0.1.0.0.99.dev12
odoo12-addon-l10n-it-fatturapa-pec==12.0.1.1.1
odoo12-addon-l10n-it-account-stamp==12.0.1.0.1.99.dev2
odoo12-addon-l10n-it-fatturapa-out-stamp==12.0.1.0.1.99.dev1
Questo almeno è ciò che faccio io e vi consiglio di fare usando setuptools-odoo.
Possiamo essere assolutamente certi della compatibilità di un modulo con una sua dipendenza, la cui ultima versione stabile fu rilasciata 5 mesi prima?
Quella che chiami ultima versione stabile, per OCA è una versione vecchia. In OCA è stabile ciò che viene rilasciato sui branch stabili su github, indipendemente dal fatto che la versione venga incrementata o meno, e che quindi esista la build "stabile" su pypi. Spesso la versione non viene incrementata anche perchè molti commit sono modifiche alle traduzioni ed il sistema delle traduzioni non va a incrementare la versione del modulo.
Per maggiori informazioni su come vengono versionati i moduli odoo: https://pypi.org/project/setuptools-odoo/#versioning
Certo... Potremmo, chiaramente, specificare tutte le versioni di tutti i moduli e di tutte le loro dipendenze all'interno dei requirements, per ovviare al problema...Ma anche qualora fosse lontanamente sostenibile andare a ricercare tutte le versioni, di tutti i moduli, di tutte le dipendenze in cascata ed eseguire tale operazione ad ogni rilascio di ogni aggiornamento, preferirei delegarla a chi è nato per questo. 😉I package manager, come in questo caso "pip", sono stati creati proprio per scaricare l'Essere Umano dall'onere di eseguire questa operazione manualmente, velocizzare tutte le operazioni di installazione ed aggiornamento, ridurre al minimo la probabilità di errore Umano (appunto) così da facilitarci la Vita e permetterci di dedicarci a quello che più ci piace e sappiamo fare meglio: scrivere codice.
pip ed il requirements.txt non sono nati per disinteressarti delle versioni che installi. Ovviamente se vuoi puoi farlo, a tuo rischio e pericolo.
Per aggiornare automaticamente il requirements.txt ci sono degli strumenti automatici. Io ad esempio uso questo https://github.com/simion/pip-upgrader con questa fix https://github.com/simion/pip-upgrader/pull/16
L'unica cosa che ci rimane da fare a noi, è iniziare a incrementare la versione dei moduli, ogni qualvolta si rilascia una nuova versione stabile (e mi pare di capire che, una PR, non viene approvata se non è considerata stabile).
Incrementare la versione del modulo in ogni PR è infatti buona pratica e di solito richiesto.
Però questo non sarebbe sufficiente ad avere su pypi solo versioni "stabili", per i motivi che dicevo sopra.
PS: se siete d'accordo potremmo proseguire la discussione sulla mailing list Italy, perchè penso possa essere molto utile per tutti.
Ciao
Lorenzo Battistini
https://github.com/eLBati
https://github.com/eLBati
Follow-Ups
