camptocamp
Partial port to click-odoo
Hi @guewen @lepistone
You know, I love marabunta. Therefore, I'm planning to do a partial port of marabunta to excellent @sbidoul's click-odoo library to have a consistent (framework-ish) API to my DevOps collection.
I'd like to ask you most to check, if you agree with the Author and contributor assignments so everything is in order and all rights are duly respected to that end.
Please check in: https://github.com/xoe-labs/click-odoo-migrator
And let me know if you're OK with it, or would like me something to change.
FYI, here is the planned (reduced) CLI api: https://github.com/xoe-labs/click-odoo-migrator/blob/0a652c64938406bdb250b3822482a1fccacbbdf1/src/migrator.py#L45-L81 It also maybe becomes clear, why I want a bare minimum migration controller. I think marabunta is maybe already past that stage. But I'll try to incorporate the odoo migration scripts which were abandoned subsequently from odoo upstream...
A good controller does what is not achievable on the module migration level. Module level migrations can then be scripted click-odoo-migrator aware leveraging odoo's mini-migration library.
EDIT: Sounds a little like OpenUpgrade lib. Hm ...
This is how far I got so far: https://github.com/xoe-labs/click-odoo-migrator/blob/master/src/migration/migration.py
The core of marabunta is condensed and stripped down to roughly 200 Lines of Code. (Not working code, yet, but you can get an idea)
I still need to provide a separate cursor for the migration table so it doesn't get interfered by the environment change during migration, I guess...
I'd like to ask you most to check, if you agree with the Author and contributor assignments so everything is in order and all rights are duly respected to that end.
Looks good to me.
The core of marabunta is condensed and stripped down to roughly 200 Lines of Code. (Not working code, yet, but you can get an idea)
Do you never need operations?
@guewen Thanks for sharing your thoughts and agreeing with the use of your code! If there is anything you spot and don't like, please let me know!
Do you never need operations?
I've spent a lot of hours swimming over the use cases. My conclusion is: In one usage scenario, pre- and post- operations are semantical competitors to pre- and post- migration scripts. In another usage scenario, I would rather use this special purpose library for data seeding and loading: https://github.com/xoe-labs/click-odoo-loader
I still thought I would need external state, in the kind of a primer, but then I saw that Odoo iterates over migrations several times so to make sure previously blocking dependencies are updated in ~idem-potential~ converging cycles, so that a corresponding pre- migration could finally run (which has equivalent effects to a pre-migration primer, but doesn't leave module state.)