Archives
Contributors
-
Re: Linting for 13.0 branches (using black and pre-commit)
+1Le lun. 7 oct. 2019 à 16:11, Damien Crier <damien.crier@camptocamp.com> a écrit :+1 tooOn Mon, Oct 7, 2019 at 3:52 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:And here is a first draft of the algorithm the bot will use to maintain the configuration files: https://github.com/OCA/oca-github-bot/issues/80On Mon, Oct 7, 2019 at 3:32 PM Sergio Corato <sergiocorato@gmail.com> wrote:+1Sergio CoratoIl giorno lun 7 ott 2019 alle ore 15:12 Stéphane Bidoul <stephane.bidoul@acsone.eu> ha scritto:Hi Simone,The beauty of pre-commit is that it installs and maintains the dependencies for you.So all you have to do is install pre-commit once, according to the instructions on the pre-commit website (I personally use pipx for that), then run 'pre-commit install' at the repo clone root, or run 'pre-commit run --all-files'.It will download and install or update all required dependencies automatically in an isolated and cached location.If you forget to do it, travis will catch the errors and display a diff with the changes you should do locally.-sbiOn Mon, Oct 7, 2019 at 2:47 PM Simone Orsi <simahawk@gmail.com> wrote:Hello Stéphane,we are already using it and we love the tool, so: +1Just an important thing: we should pay attention to documentation and ease of bootstrap this for newcomers.While I love the tool, I fear that it could be a barrier for ppl not used to it.For instance, how are you planning to make ppl install dependencies in a unique and reliable way? Via each repo/requirements.txt?Thanks for your work and your insights :)Cheers,On Mon, Oct 7, 2019 at 12:56 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Damien Crier Tel : +33 4 58 48 20 31
Camptocamp France SAS
18 rue du Lac Saint AndréSavoie Technolac - Bâtiment Le Dauphinhttp://www.camptocamp.com
F-73370 Le Bourget du Lac_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Benoît Guillot - 04:30 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
On Mon, Oct 7, 2019 at 3:12 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:It will download and install or update all required dependencies automatically in an isolated and cached location.oh, you are right. Then nothing more to do than following pre-commit setup.Thanks for the feedback.
by Simone Orsi - 04:06 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
And here is a first draft of the algorithm the bot will use to maintain the configuration files: https://github.com/OCA/oca-github-bot/issues/80On Mon, Oct 7, 2019 at 3:32 PM Sergio Corato <sergiocorato@gmail.com> wrote:+1Sergio CoratoIl giorno lun 7 ott 2019 alle ore 15:12 Stéphane Bidoul <stephane.bidoul@acsone.eu> ha scritto:Hi Simone,The beauty of pre-commit is that it installs and maintains the dependencies for you.So all you have to do is install pre-commit once, according to the instructions on the pre-commit website (I personally use pipx for that), then run 'pre-commit install' at the repo clone root, or run 'pre-commit run --all-files'.It will download and install or update all required dependencies automatically in an isolated and cached location.If you forget to do it, travis will catch the errors and display a diff with the changes you should do locally.-sbiOn Mon, Oct 7, 2019 at 2:47 PM Simone Orsi <simahawk@gmail.com> wrote:Hello Stéphane,we are already using it and we love the tool, so: +1Just an important thing: we should pay attention to documentation and ease of bootstrap this for newcomers.While I love the tool, I fear that it could be a barrier for ppl not used to it.For instance, how are you planning to make ppl install dependencies in a unique and reliable way? Via each repo/requirements.txt?Thanks for your work and your insights :)Cheers,On Mon, Oct 7, 2019 at 12:56 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 03:51 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
+1Sergio CoratoIl giorno lun 7 ott 2019 alle ore 15:12 Stéphane Bidoul <stephane.bidoul@acsone.eu> ha scritto:Hi Simone,The beauty of pre-commit is that it installs and maintains the dependencies for you.So all you have to do is install pre-commit once, according to the instructions on the pre-commit website (I personally use pipx for that), then run 'pre-commit install' at the repo clone root, or run 'pre-commit run --all-files'.It will download and install or update all required dependencies automatically in an isolated and cached location.If you forget to do it, travis will catch the errors and display a diff with the changes you should do locally.-sbiOn Mon, Oct 7, 2019 at 2:47 PM Simone Orsi <simahawk@gmail.com> wrote:Hello Stéphane,we are already using it and we love the tool, so: +1Just an important thing: we should pay attention to documentation and ease of bootstrap this for newcomers.While I love the tool, I fear that it could be a barrier for ppl not used to it.For instance, how are you planning to make ppl install dependencies in a unique and reliable way? Via each repo/requirements.txt?Thanks for your work and your insights :)Cheers,On Mon, Oct 7, 2019 at 12:56 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 03:31 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
Hi Simone,The beauty of pre-commit is that it installs and maintains the dependencies for you.So all you have to do is install pre-commit once, according to the instructions on the pre-commit website (I personally use pipx for that), then run 'pre-commit install' at the repo clone root, or run 'pre-commit run --all-files'.It will download and install or update all required dependencies automatically in an isolated and cached location.If you forget to do it, travis will catch the errors and display a diff with the changes you should do locally.-sbiOn Mon, Oct 7, 2019 at 2:47 PM Simone Orsi <simahawk@gmail.com> wrote:Hello Stéphane,we are already using it and we love the tool, so: +1Just an important thing: we should pay attention to documentation and ease of bootstrap this for newcomers.While I love the tool, I fear that it could be a barrier for ppl not used to it.For instance, how are you planning to make ppl install dependencies in a unique and reliable way? Via each repo/requirements.txt?Thanks for your work and your insights :)Cheers,On Mon, Oct 7, 2019 at 12:56 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:
- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 03:11 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
Hello Stéphane,we are already using it and we love the tool, so: +1Just an important thing: we should pay attention to documentation and ease of bootstrap this for newcomers.While I love the tool, I fear that it could be a barrier for ppl not used to it.For instance, how are you planning to make ppl install dependencies in a unique and reliable way? Via each repo/requirements.txt?Thanks for your work and your insights :)Cheers,On Mon, Oct 7, 2019 at 12:56 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:
- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Simone Orsi - 02:46 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
+1On Mon, Oct 7, 2019 at 2:31 PM Mignon, Laurent <laurent.mignon@acsone.eu> wrote:+1On Mon, Oct 7, 2019 at 2:27 PM Moises Lopez <moylop260@vauxoo.com> wrote:+1FYI Guewen and Stephane showed me “Black” in #OCADays and it looks great!It is just a plug&play tool in order to use it locally and use it from travis builds.Tell me if you need something of my part.On Mon 7 Oct 2019 at 5:56 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:--Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--__________________________________________
Denis Roussel
Software Engineer
Acsone SA, Succursale de Luxembourg
Tel : +352 20 21 10 20 19
Fax : +352 20 21 10 21
Gsm : +352 691 50 60 88Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
www.acsone.eu
by Denis Roussel - 02:40 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
Moises, if you could have a quick look at .pylintrc and .pylintrc-mandatory in https://github.com/OCA/maintainer-quality-tools/pull/613, to see if there is anything to add or change, that would be great.Also, if anyone has suggestions on javascript checks to make mandatory, it's easier to do it now than later (see .eslintrc in the same PR, currently all checks are non-blocking warnings).-sbiOn Mon, Oct 7, 2019 at 2:27 PM Moises Lopez <moylop260@vauxoo.com> wrote:+1FYI Guewen and Stephane showed me “Black” in #OCADays and it looks great!It is just a plug&play tool in order to use it locally and use it from travis builds.Tell me if you need something of my part.On Mon 7 Oct 2019 at 5:56 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:--Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:
- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 02:40 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
+1--Yves Goldberg - איב גולדברגodoo| Official Partner - OCA delegateOpen Source ERP, CRM & CMST +972 (3) 720 8818
M +972 (55) 966 1405T +32 (2) 588 2500
------- Original message -----From: "Stéphane Bidoul" <stephane.bidoul@acsone.eu>To: Contributors <contributors@odoo-community.org>Subject: Linting for 13.0 branches (using black and pre-commit)Date: Monday, October 07, 2019 13:56Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
by Yves Goldberg - 02:36 - 7 Oct 2019 - run Black before committing your code on the 13.0 branches
-
Re: Linting for 13.0 branches (using black and pre-commit)
+1On Mon, Oct 7, 2019 at 2:27 PM Moises Lopez <moylop260@vauxoo.com> wrote:+1FYI Guewen and Stephane showed me “Black” in #OCADays and it looks great!It is just a plug&play tool in order to use it locally and use it from travis builds.Tell me if you need something of my part.On Mon 7 Oct 2019 at 5:56 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:--Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Laurent Mignon - 02:30 - 7 Oct 2019 -
Re: Linting for 13.0 branches (using black and pre-commit)
+1FYI Guewen and Stephane showed me “Black” in #OCADays and it looks great!It is just a plug&play tool in order to use it locally and use it from travis builds.Tell me if you need something of my part.On Mon 7 Oct 2019 at 5:56 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:--Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Moisés López CalderónMobile: (+521) 477-752-22-30Twitter: @moylop260Twitter: @vauxoo
by Moisés López Calderón - 02:26 - 7 Oct 2019 -
Linting for 13.0 branches (using black and pre-commit)
Dear contributors,Following a recent conversation on twitter, and further talks during #OCAdays, there seems to be a wide interest for using Black [1] as a code formatter for OCA code.This post explains the proposed approach to implement it in OCA, as well as several improvements to code linting tools.In a nutshell, Black is a python code formatter that quickly gained traction in the Python community in the last couple of years. It formats the code for you with a predefined set of rules and almost no options so as to free your mind for more important matters.At #OCAdays, we discussed on how to put it in practice, and it was proposed to take the opportunity of this change to introduce pre-commit [2] as the linting framework for OCA in the 13.0 branches.TL;DR: If you are not interested in the nitty gritty details, the only change you will need to remember compared to your current workflow is:
- run Black before committing your code on the 13.0 branches
- sort imports (stdlib, odoo, odoo.addons, local imports)
- To save time, install pre-commit and run pre-commit install after cloning an OCA repository on the 13.0 branch. Linting, running black and sorting imports will be done automatically for you when you commit. You can also run it manually with 'pre-commit run --all-files'.
If you are interested in practical details and the rationale, read on.pre-commit is a tool that lets contributors easily run lint checks locally in a consistent and reproducible manner. These checks are then run again by Travis to be sure conventions are enforced. In principle this is similar to what we are doing now with MQT LINT_CHECK="1", with the following beneficial differences:- installation of the linters locally is easier: only one tool needs to be installed on developer's machines: pre-commit, which will then take care of installing all the required linters for you
- you then run "pre-commit install" after cloning a repository
- lint checks are then run automatically when creating a commit locally so you can detect errors much earlier, without having to wait for Travis to detect them for you
- some linters (such as Black, and the import sorter) fix the code for you, so you immediately have the diff available with all fixes to commit
- all configurations are stored locally in the repository using default configuration files (.pylintrc, .flake8, etc); this means your favorite IDE will pick them up automatically to give you assistance in detecting and fixing errors
- a wide variety of pre-commit plugins exist, which means we can easily benefit from them and progressively add more in the future
The proposed configuration includes the following linters:- black, with default options (to facilitate usage)
- auto fix trailing whitespace
- auto fix newline at end of files
- detect debug statements
- flake8 with same options as before (except line length which is now the 88 black default)
- pyupgrade, to encourage python 3 idioms
- pylint with mandatory checks (with some more mandatory checks than before, for v13 only)
- pylint with all checks (optional + mandatory), not failing
- isort to automatically sort imports (except in __init__.py where import order might be significant)
- run eslint as a pre-commit hook, with the same configuration as pylint-odoo except that all checks are warnings. This is the same as what pylint-odoo does (javascript checks are not blocking).
You can see an example configuration in the storage project [3], the queue project [4] as well as partner-contact [5]. Look for the following files: .pre-commit-config.yaml, .flake8, .pylintrc, .eslintrc. Also look at the updated .travis.yml to see how pre-commit is run. To try it out,- checkout these branches
- run 'pre-commit install'
- start committing lint failures to see the effect.
If you have suggestions to make on the linter configurations, you can make them on this MQT PR: https://github.com/OCA/maintainer-quality-tools/pull/613/filesIn practice, if there are no objections, the plan is to setup this configuration on all 13.0 branches this week, while there are not too many v13 modules merged. To do this, I will push all linter configuration files to 13.0 branches, as well as resetting the travis configuration to the default.When the configurations will need to evolve later, the maintenance of these configuration files will become a bot task. As before, there will be no possibility to configure linting rules per repo.Looking forward to reading your feedback.Best regards,-sbi
by Stéphane Bidoul - 12:56 - 7 Oct 2019 -
Re: How to use @api.onchange in models.AbstractModel, when the
interiting class field name are different.
Hi Kitti,AFAIS your solution with the lambda probably does not work because you are returning the field name instead of a tuple/list of fields.If you want to do it that way I suggest you use a specific method in the base model, eg:class AccountInvoiceLine(models.Model):
_name = 'account.invoice.line'
_inherit = ['analytic.dimension.line', 'account.invoice.line']
_analytic_tag_field_name = 'analytic_tag_ids'def _get_onchange_analytic_tag_spec(self):return (self._analytic_tag_field_name, )@api.onchange(self._get_onchange_analytic_tag_spec)
def _onchange_analytic_tag_ids(self):[...]Hope this helps. Bests,S.On Fri, Sep 27, 2019 at 1:31 PM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:Dear all,I have one technical challenge while doing this PR -> https://github.com/OCA/account-analytic/pull/251In the origin module, there was abstract class,
class AnalyticDimensionLine(models.AbstractModel):
_name = 'analytic.dimension.line'Which are inherited by other model, i.e., account.move.line, account.invoice.line, etc.class AccountInvoiceLine(models.Model):
_name = 'account.invoice.line'
_inherit = ['analytic.dimension.line', 'account.invoice.line']
_analytic_tag_field_name = 'analytic_tag_ids'Now, I wanted to add api.onchange method on a field which can be varied by each inheriting model via _analytic_tag_field_nameQuestion is, I would want to do the onchange on the base abstract class, analytic.dimension.line like this, but it doesn't work.class AnalyticDimensionLine(models.AbstractModel):
_inherit = 'analytic.dimension.line'@api.onchange(lambda self: self._analytic_tag_field_name) ---------------------> THIS NOT WORK
def _onchange_analytic_tag_ids(self):And so, I end up having to add @api.onchange in inheriting models. Which I think not very good.class AccountInvoiceLine(models.Model):
_inherit = 'account.invoice.line'
@api.onchange('analytic_tag_ids') ----------------------> NOT GOOD
def _onchange_analytic_tag_ids(self):Any thought are appreciated,Than you,_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Simone Orsi - 09:41 - 7 Oct 2019 -
Re: Souheil Bejaoui for project & service PSC
+1On Mon, Sep 30, 2019 at 4:27 PM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:I want to propose https://github.com/sbejaoui for this PSC as he has been working a lot on all the contract stuff. You can see some os his PRs in:Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Alex Comba
Tel (CH): +41 91 210 23 40
by Alex Comba. - 09:11 - 7 Oct 2019 -
Re: How to use @api.onchange in models.AbstractModel, when the
interiting class field name are different.
Hello Pedro,Thank you! It resolved partly, but still having to have this api.onchange on every model though.Note: I have heard a word from Rafael Odoo that, Odoo are on the way of removing api.onchange, and make api.depends more abstract in the future. May be I have to wait till then...KittiOn Fri, Oct 4, 2019 at 10:31 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:Hi, Kitti, what you can do is:class BaseModel(models.AbstractModel):_name = 'base.model'def _onchange_field_base(self, field_name):... # do whatever with field_nameclass SpecificModel(models.Model):_inherit = 'base.model'_name = 'specific.model'@api.onchange('specific_field')def _onchange_specific_field(self):return self._onchange_field_base('specific_field')Regards.El vie., 27 sept. 2019 a las 13:31, Kitti Upariphutthiphong (<kittiu@ecosoft.co.th>) escribió:Dear all,I have one technical challenge while doing this PR -> https://github.com/OCA/account-analytic/pull/251In the origin module, there was abstract class,
class AnalyticDimensionLine(models.AbstractModel):
_name = 'analytic.dimension.line'Which are inherited by other model, i.e., account.move.line, account.invoice.line, etc.class AccountInvoiceLine(models.Model):
_name = 'account.invoice.line'
_inherit = ['analytic.dimension.line', 'account.invoice.line']
_analytic_tag_field_name = 'analytic_tag_ids'Now, I wanted to add api.onchange method on a field which can be varied by each inheriting model via _analytic_tag_field_nameQuestion is, I would want to do the onchange on the base abstract class, analytic.dimension.line like this, but it doesn't work.class AnalyticDimensionLine(models.AbstractModel):
_inherit = 'analytic.dimension.line'@api.onchange(lambda self: self._analytic_tag_field_name) ---------------------> THIS NOT WORK
def _onchange_analytic_tag_ids(self):And so, I end up having to add @api.onchange in inheriting models. Which I think not very good.class AccountInvoiceLine(models.Model):
_inherit = 'account.invoice.line'
@api.onchange('analytic_tag_ids') ----------------------> NOT GOOD
def _onchange_analytic_tag_ids(self):Any thought are appreciated,Than you,_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Kitti Upariphutthiphong - 06:56 - 7 Oct 2019 -
-
Re: Website HTTP 500 Internal Server Error if logged in
On Fri, Oct 4, 2019 at 8:56 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:This should be now fixed thanks to Alexandre.Fixed for me too.Thanks, Alexandre!--Alex Comba
Tel (CH): +41 91 210 23 40
by Alex Comba. - 06:15 - 4 Oct 2019 -
Re: 13.0 Migration instructions
Yeah, thanks for the clarification.And now even with translations, the commit is done with GitHub login of each translator, so we shouldn't squash them together (unless same author) for preserving authorship.Regards.
by Pedro M. Baeza - 02:41 - 4 Oct 2019
