Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: 14.0 branches
    Ok, so you don't use all the capabilities of pip.

    With simple pip install <module> command, you will get the last version.

    You can call it with module version number too. pip install <module==version> which is managed on OCA(go to pypi, search module, you have the history).

    So, in projects, the good habit is to mention your freezed versions of modules in a project requirements. So, at any time, you can reinstall the same version of all modules chain.


    You'll discover the magic ;-)


    See you

    Le sam. 10 oct. 2020 à 00:21, Nhomar Hernández <nhomar@vauxoo.com> a écrit :
    Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).


    1.- With oca_dependencies.txt (better at module level, but not done yet).
    Current possibilities:
        a. Refer to the official dependency (pip does that).
        b. SHA A on my repo which depende of SHA B of other repo which depends of SHA C of other repo, with the effort of having change 1 line on each repo. (I think pip does not do that).
        c. run git status on a deployed instance and know the dirty done manually (I used to support some customers with pip deployed instances and they have a mess).
        d. Some artifacts on t2d are done to even freeze odoo SHA.
        e. Deploy development/test/stable on your customer using the same source of information (that can not be done by PIP never), obviously if you decide to not touch the code (which is the ideal use case in the happy path you can, but it is not the use case on the speed of development vs deployment vs production X Q instances.
        f. Refer to an specific branch on the oca_dependencies (for example to test a PR)

    With this it is pretty easy to have linked your server - CI and developing environment with 1 command '$ t2d repo' or simply read the proper files to have the information.

    2.- With PIP:

         a.- pip install module.
         b.- pray for nobody to change something because you will never know what happened.
         c.- pray the guy in charge updates the dependencies well.
         d.- If you change module B to fix module A to deploy module C you will do a nice Pray the developer is disciplined, if not kabum! only he can know what happened.

    I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!

    But if you decide to be such a disciplined guy I am ok with you guys but let's test in the CI both, I am not against having them both, On one way or another one will fix the other, but we can't force everybody to follow an strategy that is clearly not designed for the speed 200 repositories change and the asynchronous work we do.

    If you decide to go the path of killing the maintenance of oca_dependencies, as usual I support the Idea of the OCA but at least for us it will be worthless to maintain such flow if we are on our own to contribute and absorb the efficient layer that pip brings to the workflow.

    What I do think is necessary is time from the ones that consume oca_dependencies on improve the documentations and make videos to explain the power because clearly it is misunderstood and oversimplified in your analysis.

    I hope my point is better explained.

    My 2 cents.

    El vie., 9 de oct. de 2020 a la(s) 16:01, Roussel, Denis (denis.roussel@acsone.eu) escribió:
    @Nhomar I don't get the cons you've got against pip for deployments. Maybe a misunderstanding or ...

    On a wider point of view, if people relied on mechanisms like oca_dependencies.txt internally, maybe we can stay with both on this version as said before and open a discussion about that.

    But as @Stephane said, this was already created on May. Maybe a lack of communication about it (resources to do things is always the bottleneck) before deployment.

    Personally, I'd prefer pip as it allows better control. I share vision about letting things happen(feedbacks, bugs,...), debating and change. #trunkdevelopment


    Cheers!


    Le ven. 9 oct. 2020 à 21:42, Nhomar Hernández <nhomar@vauxoo.com> a écrit :
    Pip has advantages and disadvantages [1] (and manages all for the sha's as well).

    In general in deploy odoo with PIP is not even supported officially it is actually more a PoC in the OCA (which is nice but let's face it, it is not official).

    I prefer keep the current one and enable both ways (we can be free to decide which one to use).

    In general my opinion about pip is very bad (i personally don't think it is a nice way to be efficient deploying and maintaining).

    Then, if we solved properly the problem already with the tools we have and we are going to a dependency hell (that even the python community has selve it yet in 30 years) why insist?

    But again it is a democracy I think we need to mature more and more this topics and for me it is -1 change this without left proper support for both and test both ways.


    El jue., 8 de oct. de 2020 a la(s) 14:22, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    _______________________________________________
    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



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Denis Roussel - 07:55 - 10 Oct 2020
  • Re: 14.0 branches
    Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).


    1.- With oca_dependencies.txt (better at module level, but not done yet).
    Current possibilities:
        a. Refer to the official dependency (pip does that).
        b. SHA A on my repo which depende of SHA B of other repo which depends of SHA C of other repo, with the effort of having change 1 line on each repo. (I think pip does not do that).
        c. run git status on a deployed instance and know the dirty done manually (I used to support some customers with pip deployed instances and they have a mess).
        d. Some artifacts on t2d are done to even freeze odoo SHA.
        e. Deploy development/test/stable on your customer using the same source of information (that can not be done by PIP never), obviously if you decide to not touch the code (which is the ideal use case in the happy path you can, but it is not the use case on the speed of development vs deployment vs production X Q instances.
        f. Refer to an specific branch on the oca_dependencies (for example to test a PR)

    With this it is pretty easy to have linked your server - CI and developing environment with 1 command '$ t2d repo' or simply read the proper files to have the information.

    2.- With PIP:

         a.- pip install module.
         b.- pray for nobody to change something because you will never know what happened.
         c.- pray the guy in charge updates the dependencies well.
         d.- If you change module B to fix module A to deploy module C you will do a nice Pray the developer is disciplined, if not kabum! only he can know what happened.

    I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!

    But if you decide to be such a disciplined guy I am ok with you guys but let's test in the CI both, I am not against having them both, On one way or another one will fix the other, but we can't force everybody to follow an strategy that is clearly not designed for the speed 200 repositories change and the asynchronous work we do.

    If you decide to go the path of killing the maintenance of oca_dependencies, as usual I support the Idea of the OCA but at least for us it will be worthless to maintain such flow if we are on our own to contribute and absorb the efficient layer that pip brings to the workflow.

    What I do think is necessary is time from the ones that consume oca_dependencies on improve the documentations and make videos to explain the power because clearly it is misunderstood and oversimplified in your analysis.

    I hope my point is better explained.

    My 2 cents.

    El vie., 9 de oct. de 2020 a la(s) 16:01, Roussel, Denis (denis.roussel@acsone.eu) escribió:
    @Nhomar I don't get the cons you've got against pip for deployments. Maybe a misunderstanding or ...

    On a wider point of view, if people relied on mechanisms like oca_dependencies.txt internally, maybe we can stay with both on this version as said before and open a discussion about that.

    But as @Stephane said, this was already created on May. Maybe a lack of communication about it (resources to do things is always the bottleneck) before deployment.

    Personally, I'd prefer pip as it allows better control. I share vision about letting things happen(feedbacks, bugs,...), debating and change. #trunkdevelopment


    Cheers!


    Le ven. 9 oct. 2020 à 21:42, Nhomar Hernández <nhomar@vauxoo.com> a écrit :
    Pip has advantages and disadvantages [1] (and manages all for the sha's as well).

    In general in deploy odoo with PIP is not even supported officially it is actually more a PoC in the OCA (which is nice but let's face it, it is not official).

    I prefer keep the current one and enable both ways (we can be free to decide which one to use).

    In general my opinion about pip is very bad (i personally don't think it is a nice way to be efficient deploying and maintaining).

    Then, if we solved properly the problem already with the tools we have and we are going to a dependency hell (that even the python community has selve it yet in 30 years) why insist?

    But again it is a democracy I think we need to mature more and more this topics and for me it is -1 change this without left proper support for both and test both ways.


    El jue., 8 de oct. de 2020 a la(s) 14:22, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    _______________________________________________
    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



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    by Nhomar Hernández - 12:21 - 10 Oct 2020
  • Re: 14.0 branches
    @Nhomar I don't get the cons you've got against pip for deployments. Maybe a misunderstanding or ...

    On a wider point of view, if people relied on mechanisms like oca_dependencies.txt internally, maybe we can stay with both on this version as said before and open a discussion about that.

    But as @Stephane said, this was already created on May. Maybe a lack of communication about it (resources to do things is always the bottleneck) before deployment.

    Personally, I'd prefer pip as it allows better control. I share vision about letting things happen(feedbacks, bugs,...), debating and change. #trunkdevelopment


    Cheers!


    Le ven. 9 oct. 2020 à 21:42, Nhomar Hernández <nhomar@vauxoo.com> a écrit :
    Pip has advantages and disadvantages [1] (and manages all for the sha's as well).

    In general in deploy odoo with PIP is not even supported officially it is actually more a PoC in the OCA (which is nice but let's face it, it is not official).

    I prefer keep the current one and enable both ways (we can be free to decide which one to use).

    In general my opinion about pip is very bad (i personally don't think it is a nice way to be efficient deploying and maintaining).

    Then, if we solved properly the problem already with the tools we have and we are going to a dependency hell (that even the python community has selve it yet in 30 years) why insist?

    But again it is a democracy I think we need to mature more and more this topics and for me it is -1 change this without left proper support for both and test both ways.


    El jue., 8 de oct. de 2020 a la(s) 14:22, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Denis Roussel - 11:01 - 9 Oct 2020
  • Re: 14.0 branches
    Pip has advantages and disadvantages [1] (and manages all for the sha's as well).

    In general in deploy odoo with PIP is not even supported officially it is actually more a PoC in the OCA (which is nice but let's face it, it is not official).

    I prefer keep the current one and enable both ways (we can be free to decide which one to use).

    In general my opinion about pip is very bad (i personally don't think it is a nice way to be efficient deploying and maintaining).

    Then, if we solved properly the problem already with the tools we have and we are going to a dependency hell (that even the python community has selve it yet in 30 years) why insist?

    But again it is a democracy I think we need to mature more and more this topics and for me it is -1 change this without left proper support for both and test both ways.


    El jue., 8 de oct. de 2020 a la(s) 14:22, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    by Nhomar Hernández - 09:41 - 9 Oct 2020
  • Re: 14.0 branches
    > Doing both if it's the contributor's responsibility to maintain oca_dependencies.txt and requirements.txt, then I'd say no because it will create additional burden on contributors.

    Ok, how did you plan restore old behaviour like your first thread told us?
     - "Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml"

    Without these files the old behaviour is disabled totally.
    Is not?

    > 2a. do people rely on the presence of oca_dependencies.txt and requirements.txt in their workflow ?
    2b. do we want to guarantee their presence and correctness ?

    For us today the answer for both are: yes

    We are deploying using these files today.
    In fact, we have a report of each sha and you can open a url with production sha vs staging one in order to see what changes were created.
    In this report we have a warning if there is a repository with custom changes ("git status" feature).
    if I like make a custom change for my oca-fork it is not an easy way to redirect all repositories to my organization like oca_dependencies.txt (we only change OCA by Vauxoo in the MQT script)

    So, we will be forced to make a Python Package Repository to have our fork green.
    I understand that we could loose these features using pip but I like the advantages using pip.

    If we were warned a time ago, maybe we could think how to change it or prevent the effects and discuss it.

    > That is a double open question, to be debated. 

    I agree with you.
    This matter should be debated, with a good time before to decide change it

    Conclusion
    if both builds can't be enabled for 14.0
    and 14.0 was already released 1 week ago.
    Should we change the current way for 14.0 today even if it wasn't discussed before?

    by Moisés López Calderón - 08:11 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Moises,

    On Fri, Oct 9, 2020 at 4:11 PM Moises Lopez <moylop260@vauxoo.com> wrote:
    What about enable 2 builds for 14.0?
    1. oca_dependencies
    2. pip
     
    Doing both if it's the contributor's responsibility to maintain oca_dependencies.txt and requirements.txt, then I'd say no because it will create additional burden on contributors.

    I see two questions here:

    1. does MQT_DEP=PIP have issues/warts ?

    To the best of my knowledge it does not have functional regressions compared to oca_dependencies.txt and it has several advantages.
    It may have some issues. We don't know yet for sure, because it's still young,
    Although it has been tested for a few months on several 13.0 repos, only time will tell.

    2a. do people rely on the presence of oca_dependencies.txt and requirements.txt in their workflow ?
    2b. do we want to guarantee their presence and correctness ?

    That is a double open question, to be debated. 
    I personally would not recommend it.
    But if the answer is yes and yes, then we'll need to see what to do.

    -sbi

    by Stéphane Bidoul - 06:56 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Stéphane Bidoul

    Thank you for your hard work here.

    I understand the advantages and disadvantages using pip or oca_dependencies

    You mentioned that it is so easy to switch from a way to another one, but I'm not sure since that if all repo won't have oca_dependencies.txt and requirements.txt files so dual compatibility is not guaranteed.

    I mean, if I have a project using oca_dependecies it depends of one that is not using oca_dependencies... so the script won't be able to know what other repositories should be cloned.

    But I don't like disable totally the pip way .

    What about enable 2 builds for 14.0?
    1. oca_dependencies
    2. pip

    It will allow us see the pros and cons for both ways and take a better decision for 15.0

    --
    Moisés López Calderón
    Mobile: (+521) 477-752-22-30
    Twitter: @moylop260
    hangout: moylop260@vauxoo.com
    http://www.vauxoo.com - Odoo Gold Partner
    Twitter: @vauxoo
    by Moisés López Calderón - 04:10 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Daniel,

    IMO even if you see the list of repositories you still don't know which module is used and by whom.

    On the contrary, with the dependency coming from python packages, you can list the tree of the dependencies pretty easily.

    Cheers,

    On Fri, Oct 9, 2020 at 3:11 PM Daniel Reis <dreis@opensourceintegrators.com> wrote:
    On 09/10/2020 11:32, Stéphane Bidoul wrote:


>


> @Simone, I think it's too early to say the other way is deprecated. 


> Let's give it some time.


>

Thank you for this work,

The oca-dependencies.txt solution was a bit clumsy, and probably it is a 
good thing that is is being sunset.

But I miss a way to get the equivalent information it gives me today.
If I deploy from Git sources (I think most people do), the 
oca-dependencies.txt gives me good clues about what other OCA repos I 
should be also including in my project.

I see some frustration coming, from not knowing what other repos we need 
to deploy to make the used modules work.
Forcing people to still maintain oca-dependencies.txt is not a good 
solution. Since it is not used in tests it is not assured to be 
reliable, and it will still have the problem of being a repo-wide 
dependency, and possibly too much for the particular modules I'm 
interested in..

I would rather prefer to have a way to have the dependency repo 
information, based on particular modules.
It would be perfect if I could run a command that would five me this 
information.
If not possible, we should required the module README to state these 
dependencies, in the Install section.

Thanks
Daniel

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
    by Simone Orsi - 03:46 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Daniel,

    I agree that oca_dependencies.txt remains valuable as documentation and was thinking about that too.

    A good source to know in which repo each addon is located is odoo-community.org/apps.
    Another one is pypi.org where each addon has a Homepage link to the repo.

    It's probably quite easy to write a script that extracts that information from a list of addon names, and eventually generate oca_dependencies.txt.

    @Denis, I agree with you of course, but the point here is certainly not to force everyone to use that method in their own projects.

    -sbi

    On Fri, Oct 9, 2020 at 3:11 PM Daniel Reis <dreis@opensourceintegrators.com> wrote:
    On 09/10/2020 11:32, Stéphane Bidoul wrote:


>


> @Simone, I think it's too early to say the other way is deprecated. 


> Let's give it some time.


>

Thank you for this work,

The oca-dependencies.txt solution was a bit clumsy, and probably it is a 
good thing that is is being sunset.

But I miss a way to get the equivalent information it gives me today.
If I deploy from Git sources (I think most people do), the 
oca-dependencies.txt gives me good clues about what other OCA repos I 
should be also including in my project.

I see some frustration coming, from not knowing what other repos we need 
to deploy to make the used modules work.
Forcing people to still maintain oca-dependencies.txt is not a good 
solution. Since it is not used in tests it is not assured to be 
reliable, and it will still have the problem of being a repo-wide 
dependency, and possibly too much for the particular modules I'm 
interested in..

I would rather prefer to have a way to have the dependency repo 
information, based on particular modules.
It would be perfect if I could run a command that would five me this 
information.
If not possible, we should required the module README to state these 
dependencies, in the Install section.

Thanks
Daniel

    _______________________________________________
    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:46 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Daniel,


    You can test the excellent pip deepfreeze https://pypi.org/project/pip-deepfreeze/ which includes a tool to see the dependencies tree of your project.

    Indeed, it requires you install an environment with pip. But after few weeks of use, you won't want to use something else ;-)

    Le ven. 9 oct. 2020 à 15:11, Daniel Reis <dreis@opensourceintegrators.com> a écrit :
    On 09/10/2020 11:32, Stéphane Bidoul wrote:


>


> @Simone, I think it's too early to say the other way is deprecated. 


> Let's give it some time.


>

Thank you for this work,

The oca-dependencies.txt solution was a bit clumsy, and probably it is a 
good thing that is is being sunset.

But I miss a way to get the equivalent information it gives me today.
If I deploy from Git sources (I think most people do), the 
oca-dependencies.txt gives me good clues about what other OCA repos I 
should be also including in my project.

I see some frustration coming, from not knowing what other repos we need 
to deploy to make the used modules work.
Forcing people to still maintain oca-dependencies.txt is not a good 
solution. Since it is not used in tests it is not assured to be 
reliable, and it will still have the problem of being a repo-wide 
dependency, and possibly too much for the particular modules I'm 
interested in..

I would rather prefer to have a way to have the dependency repo 
information, based on particular modules.
It would be perfect if I could run a command that would five me this 
information.
If not possible, we should required the module README to state these 
dependencies, in the Install section.

Thanks
Daniel

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Denis Roussel - 03:21 - 9 Oct 2020
  • Re: 14.0 branches 
    On 09/10/2020 11:32, Stéphane Bidoul wrote:

>

> @Simone, I think it's too early to say the other way is deprecated. 

> Let's give it some time.

>

Thank you for this work,

The oca-dependencies.txt solution was a bit clumsy, and probably it is a 
good thing that is is being sunset.

But I miss a way to get the equivalent information it gives me today.
If I deploy from Git sources (I think most people do), the 
oca-dependencies.txt gives me good clues about what other OCA repos I 
should be also including in my project.

I see some frustration coming, from not knowing what other repos we need 
to deploy to make the used modules work.
Forcing people to still maintain oca-dependencies.txt is not a good 
solution. Since it is not used in tests it is not assured to be 
reliable, and it will still have the problem of being a repo-wide 
dependency, and possibly too much for the particular modules I'm 
interested in..

I would rather prefer to have a way to have the dependency repo 
information, based on particular modules.
It would be perfect if I could run a command that would five me this 
information.
If not possible, we should required the module README to state these 
dependencies, in the Install section.

Thanks
Daniel
    by Daniel Reis - 03:11 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Pedro,

    I'm just trying to simplify and resolve the issue we have with the current approach.
    Maybe this will create other issues we don't know yet, we'll see.
    It's trivial to come back to the previous behaviour anyway if needed.

    Regarding the case you mention, it should not be a problem because the wheel is built immediately to the OCA wheelhouse by /ocabot merge (it's only the publishing to PyPI that occurs nightly but travis gives priority to the wheelhouse).

    @Simone, I think it's too early to say the other way is deprecated. Let's give it some time.

    -sbi

    On Fri, Oct 9, 2020 at 12:21 PM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:
    I'm not sure about this change massively without asking. I know you always want PIP everywhere, but this can have a lot of unpredicted side effects. The first I'm thinking of, if I don't know bad the mechanism, it's the following:

    - 2 PRs with module A and a module B depending on A.
    - We merge module A.
    - Rebasing nor restarting module B Travis will work until the wheel is built that night.

    Is that true or am I wrong? I know this can be workarounded through test-requirements.txt, but it means 2 changes, while in the other mode, it was not needed.

    Regards.

    _______________________________________________
    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 - 12:30 - 9 Oct 2020
  • Re: 14.0 branches
    I'm not sure about this change massively without asking. I know you always want PIP everywhere, but this can have a lot of unpredicted side effects. The first I'm thinking of, if I don't know bad the mechanism, it's the following:

    - 2 PRs with module A and a module B depending on A.
    - We merge module A.
    - Rebasing nor restarting module B Travis will work until the wheel is built that night.

    Is that true or am I wrong? I know this can be workarounded through test-requirements.txt, but it means 2 changes, while in the other mode, it was not needed.

    Regards.
    by Pedro M. Baeza - 12:20 - 9 Oct 2020
  • Re: 14.0 branches
    Yep, I know the behavior ;)
    I was just wondering if we are going to deprecate the old way or not.
    Thanks again!

    On Fri, Oct 9, 2020 at 11:51 AM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    Hi Simone,

    On Fri, Oct 9, 2020 at 9:56 AM Simone Orsi <simahawk@gmail.com> wrote:
    Regarding MQT_PIP: does it mean we `oca_dependencies.txt` is dead from v14 on?

    With MQT_DEP=PIP (which is set in .travis.yml in 14.0 branches), oca_dependencies.txt and requirements.txt are not used by travis.
    With MQT_DEP=OCA or MQT_DEP absent, it still works like before.

    So we can't say it's "dead" yet but let's see if we can do without.

    -sbi

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
    by Simone Orsi - 12:11 - 9 Oct 2020
  • Re: 14.0 branches
    Hi Simone,

    On Fri, Oct 9, 2020 at 9:56 AM Simone Orsi <simahawk@gmail.com> wrote:
    Regarding MQT_PIP: does it mean we `oca_dependencies.txt` is dead from v14 on?

    With MQT_DEP=PIP (which is set in .travis.yml in 14.0 branches), oca_dependencies.txt and requirements.txt are not used by travis.
    With MQT_DEP=OCA or MQT_DEP absent, it still works like before.

    So we can't say it's "dead" yet but let's see if we can do without.

    -sbi
    by Stéphane Bidoul - 11:50 - 9 Oct 2020
  • Odoo and Snaplogic
    Hi Folks,

    I am wondering if someone has already connected Odoo with Snaplogic?
    Is there something available or on-going around the community?

    Thanks for your help.

    __________________________________________
    Cédric Pigeon
    Project Leader
    Acsone SA, Succursale de Luxembourg

    Acsone sa/nv
    Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels  | Belgium
    Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
    www.acsone.eu
    ___________________________________________
    by Cédric Pigeon - 10:40 - 9 Oct 2020
  • Re: 14.0 branches
    Merci beaucoup Stephane !

    camptocamp
    INNOVATIVE SOLUTIONS
    BY OPEN SOURCE EXPERTS

    Frédéric Clementi
    Odoo Consultant
    Business Solutions

    +41 21 619 10 41



    Le ven. 9 oct. 2020 à 09:56, Simone Orsi <simahawk@gmail.com> a écrit :
    Thank you Stephane, Jairo and all the ones involved in this important work!

    Regarding MQT_PIP: does it mean we `oca_dependencies.txt` is dead from v14 on?



    On Thu, Oct 8, 2020 at 9:22 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by Frédéric Clementi - 10:21 - 9 Oct 2020
  • Re: 14.0 branches
    Thank you Stephane, Jairo and all the ones involved in this important work!

    Regarding MQT_PIP: does it mean we `oca_dependencies.txt` is dead from v14 on?



    On Thu, Oct 8, 2020 at 9:22 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe



    --
    Simone Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
    by Simone Orsi - 09:55 - 9 Oct 2020
  • Re: 14.0 branches
    Thanks a lot for this huge work

    Bonne journée


    David BEAL - akretion.com
    Consultant
    Odoo Intégration / Développement


    Le jeu. 8 oct. 2020 à 21:22, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

    _______________________________________________
    Mailing-List: https://odoo-community.org/groups/contributors-15
    Post to: mailto:contributors@odoo-community.org
    Unsubscribe: https://odoo-community.org/groups?unsubscribe

    by David BEAL - 08:35 - 9 Oct 2020
  • 14.0 branches
    Dear fellow contributors,

    The 14.0 branches are being created as I post this message.

    They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

    Special thanks to Jairo Llopis for his work on this topic.

    I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

    1. The project description in README.md must be updated manually by PSCs.

    Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

    2. Travis installs dependencies with pip, including addons of other repos

    This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

    The main expected benefits are:
    - less redundancy (the manifests are enough to discover dependencies)
    - reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

    If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


    This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

    3. If you need local changes to the dotfiles let's discuss them

    There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

    If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

    As usual, don't hesitate to let me know of any issue.

    That's all for now, folks. Happy migration!

    -sbi


    --
    Stéphane Bidoul | @SBidoul
    Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120
    by Stéphane Bidoul - 09:21 - 8 Oct 2020