acsone / bobtemplates.odoo Goto Github PK

The import statement in the model file should be reorganized.

If not, close.

Given that it's likely that not all my contributions are going to be welcome, is there a sensible way (or can such be created) to easily write custom extensions to acsone/bobtemplates.odoo?

@sbidoul
Good job thanks!

FYI the following python pure library cookiecutter save a configuration file with your command line choices.
This allow you to regenerate the full project meta-files with new changes/updates E.g. .travis.yml, .tox

For the case of this project, maybe we could use this technical to reuse a configuration file to create a new module based on configuration stored as default value.

Question: The final focus of this project... Is create a scaffold (just create modules) or a cookiecutter (create full project too)?

run on windows10 and python27:

(venv) c:\Users\qq470647251\Desktop>mrbob bobtemplates.odoo:addon

File "d:\p\odoo-11.0\venv\lib\site-packages\bobtemplates\odoo\hooks.py", line 37, in _delete_file
os.remove(path)
WindowsError: [Error 3] : u'c:\Users\qq470647251\Desktop\test/README.rst.oca'

If not, close. :)

What about a new migration template that would generate migration script for a given module?
When being in the current module's directory: mrbob bobtemplates.odoo:migration

It would ask for:

• new module version
• use openupgrade? (yes/no)
• pre-migrate? (yes/no)
• post-migrate? (yes/no)

And then it would:

• generate the migrations/{version_number}/(pre/post)-migrate.py file(s)
• import logging and add a default _logger.info() message in the migrate method
• if the use of openupgrade is selected:
  • import openupgrade
  • add the @openupgrade.migrate(use_env=True) decorator and use the env variable in the migrate method
  • add openupgradelib to the external dependencies of the manifest
• change the version of the module accordingly

If it's relevant, the same could be done for pre/post-init hooks (I can write a separate issue for that).

@sbidoul Is a new release planned ?

Thanks

among others pylint requires / strongly suggests it and could enforce good practice. Not 100% sure if a sensible way of dealing with docstrings can be found in an odoo context, but at least if inherit == False, it could be made required.

Encourages thinking before doing ... 😉