More switches to disable unneeded actions (version change, black, etc)

[katyukha]

Hi,

Thanks for this interesting project) It is looking as a nice way to automate module migration routines, but i have the question.

Is it possible to avoid applying Black to code? The reason is, i would like to try to use this project in forward-ports workflow, but we try to do minimum changes during forwardport. So, Black may introduce a lot of unneeded changes in git. Also, forward-ports are repeatable actions, because 90% of our modules we develop on 11.0 branch and then periodically forward-port changes to 12.0 and 13.0 branches.

My expectations after running module migration is following:

• No module version changed (in our forkflow it will be done by odoo-helper-scripts
• No enforced formatting of code
• Only changes related to migration of module to newer odoo serie have to be applied.

[katyukha]

One more question: Why "removing migrations folders"?

In our case, during forwardport migration folder have to be renamed to new serie. For example: 11.0.1.78.0 -> 12.0.1.78.0

[flachica]

One more question: Why "removing migrations folders"?

In our case, during forwardport migration folder have to be renamed to new serie. For example: 11.0.1.78.0 -> 12.0.1.78.0

Migration script are specifics from the version. If you rename the folder, the same code will be executed from 10 to 11 than 11 to 12 and this is an error

This is the reason because you need remove migration folder

[flachica]

Hi,

Thanks for this interesting project) It is looking as a nice way to automate module migration routines, but i have the question.

Is it possible to avoid applying Black to code? The reason is, i would like to try to use this project in forward-ports workflow, but we try to do minimum changes during forwardport. So, Black may introduce a lot of unneeded changes in git. Also, forward-ports are repeatable actions, because 90% of our modules we develop on 11.0 branch and then periodically forward-port changes to 12.0 and 13.0 branches.

My expectations after running module migration is following:

* No module version changed (in our forkflow it will be done by [odoo-helper-scripts](https://github.com/katyukha/odoo-helper-scripts)

* No enforced formatting of code

* Only changes related to migration of module to newer odoo serie have to be applied.

Take a look in this point of documentation if --no-commit solve your workflow

[katyukha]

1. About migration scripts. Let me describe our case. We keep same functionality for all three version: 11.0, 12.0, 13.0. And we use same version naming: 11.0.1.78.0, 12.0.1.78.0,13.0.1.78.0. And when we introduce migration for 11.0.1.78.0 version, same code have to be executed for 12.0.1.78.0 and 13.0.1.78.0 versions. So, in my case, it would be better to be able to disable migration removal.

2. No commit is not enough, because it poducess too much unwated changes that must be reviewed manually. For example, in repository we have near 50 modules, and when we do forwardport, we want ot have only small set of changes related to forward-ported functionality. Currently, when i use --no commit for repository with single module compatible (no big differences) with 12.0 and 13.0, odoo-module-migrator produces a lot of changes related to styles (replaces quotes from single quote to double quote, etc). Is there a way to disable this?

[flachica]

For solve 1. you can use hooks in module. If you dont have the 13.0 code, you can not know what code to execute in this version.

[flachica]

Point 2: I run code from master branch and not reformat code style. I agree with you that you should only correct the code style if you want to. In fact, the author asks for help here. Reformat code must be executed if pre-commit config file exists

[katyukha]

What do you mean hooks?

About 13.0 code, yes, it seems that such migration will be executed for all odoo series.

In our case, it is related to our versioning scheme: "S.S.V.V.P", where "S.S" - odoo serie, "V.V" module version, "P" - serie-specific patch. Thus same module version could be available for multiple odoo series. And in case, when we forward-port changes from 12.0 to 13.0, we do not want to start versioning from 1.0.0, instead we want to keep same version. Also, in case of migration, during forward-port, they have to be reviewed manually and adapted (if needed) to next odoo serie. Such versioning scheme allows us to have unified changelogs across multiple odoo series and easily track what feature in what version (independent of serie) was introduced.

So, i think it would be nice to have a switch (option) to disable automatic removal of migrations.

So, currently, i am thinking about the way to use this project in our workflows, may be integrate it with odoo-helper-scripts. Ideally, i would like to have some console utils which i can install via pip and run for some module, to find and fix pieces of code that have to be migrated (from 12.0 to 13.0, etc), like usage of sudo(user). Without inplace code formatting, version change, migration removal and so on. And from my side of view, such command may be run against single module multiple times. For example, we support 2 odoo series for some module (12.0 and 13.0). We develop all new features on 12.0 and then forward-port then to 13.0. And after we implement something for 12.0 in same module, i would like to forward port it to 13.0, and run this module, to fix incomatible pieces of code.

From my point of few, there have to be some core entity of this project, that will do only migration of module (no version change, no formatting, no migration removal, etc). And there have to be the way to use (for example import from another python module) only this core entity.

[flachica]

I understand. Thanks for explanation.

IMO, for take into account this proposition, the authod must approbe this request.

For problems related with black I recent send this PR