Archives
Contributors
-
Re: 14.0 branches
I totally agree with Nhomar, and I want to add a point: even if pip improves the consumption as Nhomar says, it diverges the way you do that operation and the potential future one: to contribute. If people consumes Odoo in their early times through pip, and later want to contribute, they will need to learn a lot about the internals with all the wheel, setup folder, dependencies override (this has been fixed since v13 though), etc stuff, and finally GIT for being able to streamline their new flow while starting from the beginning with GIT, they will have the same flow all the time. That's my main reason for not liking PIP (apart from all the middle stuff it needs to be generated and to mangle Odoo config file for making it work).Regards.
by Pedro M. Baeza - 12:21 - 12 Oct 2020 -
Re: 14.0 branches
Hi Nhomar,- SHA management with git is fully supported: pip install <addon-name> <git-url>@<sha>#subdirectory=<setup dir>
- didn't catch second point.
On Mon, Oct 12, 2020 at 12:07 PM Nhomar Hernández <nhomar@vauxoo.com> wrote:Hello Laurent and all.El lun., 12 de oct. de 2020 a la(s) 02:07, Mignon, Laurent (laurent.mignon@acsone.eu) escribió:HI Folks,I think it's very important to keep the debate open and to present your arguments in a constructive way.I must admit that I am a little saddened to read accusations of half-truths when the process is meant to be open and constructive. It seems to me that the goal here is not to impose a new methodology but to confront our practices with those of the python community.Me too!But I think what we are having now is a "coup d'etat" and nobody in charge is answering (at least what I see) the questions.I want and will be Open and argumenting constructively, but to be fairly honest, 3 things are clear for me we can not do with pip (and I am not moving forward until those are not solved and the reasons all was born, I can not be constructive when somebody come to brake everything is built even with the best of the intentions).1.- No SHA management present in PIP linked with git (or if it is an extra layer BTW).2.- No Oca dependencies (remember it is not optional nor auto done, We need to have one and only one place where to say technically where is my dependency code) , which means if PIP consume oca_dependencies then nice, but not make us to re-create all into PIP and then auto create a oca_dependency.txtI have an honest question:Do you think Odoo will be pip-installable in some moment?I see communities like tryton and plone that claim be so so so pip lovers and python perfectionists, and I personally have FAST way to consume (with PIP) but **really complex way** to contribute, because PIP is a tool to improve the **pull** process not the **push** process.Why do we insist on changing all to PIP when we have a flow that works!? and in fact, each time I take a customer that deploys with PIP they have a perfect mess, nobody knows anything about nothing.The fact that the aim of this approach is to simplify the maintenance of our OCA repositories as well as to reduce the learning curve for new developers, I find this more than remarkable and valuable.
Since many integrators' tools/processes are now based on the oca_dependencies.txt and requirement.txt files, in view of the discussion it seems necessary that somehow these should be available again. It seems to me that automating the generation of these files would be more than beneficial because it would avoid inconsistencies in the future for all the processes based on them.I need to say man to be honest, there is no proof that if we change to PIP more people will contribute (there is non a single proof this will happen), In fact I think it will increase the consumption of modules but it will decrease the actual contribution.Why?Because you are separating process from develop-deploy-consume on different tools then this will be impossible to use the same effort to contribute and people with come down with the contribution.
Over the years I have used different tools and methodologies to try to improve the management of our dev -> prod processes of our python projects. I personally contributed to buildout, imagined and wrote git-agggregator, .... The goal has always been to improve the traceability and reproducibility of our developments and deployments. Today, and thanks to the evolutions around pip, I'm happy to see that python tools allow me to improve and simplify these processes without having to use specific tools. (While bringing more freedom and features).And me too!But what I do not know how to explain myself and it looks like I am alone on this battle is:PIP is not a tool to **contribute** with the code but to **distribute** the code.Then, it will not improve the collaboration, it will increase (and it is nice) the consumption of the software, but say that other pythonists will come easier because PIP is not true.IMHO this should be the approach (as any other package).code -> oca_dependencies > download dependencies -> test packages IF Ok then generate the new version for a pIP package test the PIP package and END.What I understand (and please correct me if I am wrong) is that you want to start to maintain PIP packages and ignore completely the current approach, and I can't find a way or a single reason why loose the flexibility that a single file gives us (the opca_dependencies) as centralizer.Note: I am pretty sure the current mechanism has other issues but that in particular for me is the no-go topic.
Is it possible to envisage an evolution of our integration mechanisms towards pip support while retaining the necessary elements for the other approaches developed by the various parties?I am IN but not on this way, let's at least make a plan together and inform a proper time (not overnight when a version which almost all modules will work from the old one was just released).
I find it motivating to confront this approach with all the use cases of each other in order to determine the limits of this approach. This will at least allow us to improve our knowledge and perhaps correct certain ideas.Me too!RegardsI ask for apologize If I am being rude, but I can't find other ways to be clear/plain and simple about my point.Regards.On Mon, Oct 12, 2020 at 12:11 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:El dom., 11 de oct. de 2020 a la(s) 12:17, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:As said, my only goal is to improve the OCA contribution workflow.Of course, I don't want to force any specific installation method onto integrators workflows.Sorry my friend, but if you continue insists that the Integration, deployment and testing are separated and differently managed, then you are doing and proposing exactly the opposite here.Everybody should deploy/test/use the software in the same unique way (the only difference should be the extra dependencies required for the testing environment itself that are not required in production, and even this can be used in production as well but some prefer not doing it.So let's try to keep the discussion focused.To be a little bit more specific, here are some aspects that the new method improves:Less RedundancyWhat is in requirements.txt must be added manually and is redundant to addons manifests. oca_dependencies.txt is also redundant and the information can be found elsewhere.Why oca_dependencies is redundant? currently, Where else I can find that information?
Better testing of dependency declarations
We don't test external python dependencies declarations in manifests because we rely on a redundant, manually maintained requirements.txtWith PIP this will happen too! (that's the problem with the pip-hell that I linked my friend).pylint-odoo helps but there are limits to what it can detect.The same in the other way around, pylint-odoo was born because we need to test things that need odoo running and/or a very specific odoo environment.
Also, we publish wheels for OCA addons because it is by far the easiest for newcomers (and veterans alike I should say) to discover dependencies (addons and external python dependencies). Bad dependencies makes for a suboptimal user experience for newcomers installing the wheels.I think the opposite here, (I am a veteran python consumir as you are, and honestly I prefer 100% read how to deploy odoo than deal with pip-hell).But in this case you get a point which is the newcomers we should teach more and document better the current process, not remove features for them (it is dangerous in the long term).
Reduced blast radius when addons are introduced with specific test requirements, or "exotic" test requirements break
When an addon has specific test requirements it has side effects in all repos that transitively depend on its repo, whether or not the modules are actually needed. When installing dependencies at the addon level instead of the repo level, we drastically reduce the blast radius of such things. Examples: server_environment that required a mandatory option in odoo.cfg. Or an obscure dependency of some rarely used addon in server-tools that suddenly breaks on PyPI and impacts all repos that transitively depend on server-tools because they all end up installing all requirements.txt of server-tools. When that happens, the impact is usually so wide that everyone has to rush to find solutions to unlock the situation. If the impact is contained to the addon and those that depend on it, that buys us more time to find good solutions.But this is only solved if we move the dependencies (the current one) to module level, not change all to PIP.On the other hand, you get a point!, solution: Avoid tools that change the odoo.cfg modification as a good practice, but that's another story..Finer grained approach to declaring unmerged dependenciesWith the optional test-requirements.txt, you can declare override dependencies to target unmerged individual addons like this:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}WAO:How i that simplest that say:folder git@url/repo branch ?This means you can reference several PRs of the same repos, or several addons of different PRs in another repo (I don't think one can do that with oca_dependencies.txt, where you reference whole repos).Same as above.[BTW, @Moises, to answer your question above you could use such references to your own repos. And it reduces the need to use git-aggregator too. - but I digress]To close the list, I'd say dependency management is hard and relying on the broader python ecosystem to solve the problem can only help us in the long run (pip in particular is going to release a new sophisticated dependency resolver later this year).I think we should wait for that, I have 5 years hearing this will happen from Python Foundation and it is more complicated than ever with the expansion of python. By that time we should wait for that PEP and understanding it before move all.And Odoo is not particularly messy nor does it have anything very special in that matter.So how can we progress?For the reasons above, I'd like to move out of the status quo.In the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete.From me you received the same arguments I am giving here... it is not that simple, I am fully worried, you are saying half/truths here, almost all the arguments are incomplete.But that's another topic here.So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback.Solid feedback:Let's use pip BUT the old way too, until the PIP is stable and we can seriously have something solid.I am fully worried, we end up with a Frank-PIP as well which will return us to the same point we are today but with PIP.Your half/true statements to be fairly honest, shows that neither you or us will agree because neither we want to deal with PIP-hell until Odoo supports it, and you are not working with the current status Quo.I think the blocking point is ther.No harm is done (there are no cross-repo dependencies in v14 branches yet :) and as said, we can easily push an update to .travis.yml.No man, there is.We are deploying v14 since 4 month ago.We have even saas-XX repos preparing thing to be migrated.Tis is not something that must be done in September pre-experience.Let' s work for version 15 from now on (or even 16) to prepare the future.With the new fast migration strategy in Odoo, we can not make this change now, for december we will have a ton of migrated databases and left OCA behind too much.
And the good thing is that the feedback is coming:- At this point I see Moises who says it relies on oca_dependencies.txt in its workflow.- Daniel mentioned a documentation value of oca_dependencies.txt.A few questions:- @Moises, do you rely on requirement.txt too in your own workflow ?Yes, we do.- Do others rely on it ? (for instance, does Dooba need oca_dependencies.txt, requirements.txt in OCA repos ?)Yes, we do!
If we conclude that oca_dependencies.txt and/or requirements.txt must be preserved in all repos in v14 (and I'm totally fine with that), we can then discuss how best to do it.Not just preserve it (it is not a matter of have a file man, please I ask you to not oversimplify this) All the CI is and will rely on such files too!, if not you are forcing people to re-write such information in a dummy file (PIP-s way) please..Either manual with e.g. PIP mode on Odoo and OCA mode on OCB as Moises suggested - but that would be a burden for contributors to understand and maintain both approaches. Or try to generate oca_dependencies.txt and requirements.txt, which should be feasible at first sight, but that's more work. Or keep the status quo :/The easiest way is if you update your workflow instead try to change the current one to something that will left all incomplete....But again on my side I think or both or the current one.
Cheers,-sbiregards!On Sun, Oct 11, 2020 at 7:06 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.-sbi_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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 Liège (Val Benoît)
Tel : +32 2 888 31 49
Fax : +32 2 888 31 59
Gsm : +32 472 22 00 57Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | BelgiumQuai Banning, 6 (Val Benoît) | B-4000 Liège | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
by Denis Roussel - 12:21 - 12 Oct 2020 -
Re: Is there a way to create account.analytic.line from stock.move?
Which OCA module generates analytic entries (is the same as Analytic Items - i.e. account.analytic.line)? Radovan On pondelok 12. októbra 2020 12:00:27 CEST Dominique k wrote: > I haven't looked at all of the modules related to analytic in OCA. > In general, the analytic entries are created by invoices, timesheets (odoo > standard), and stock move (with OCA module) > > however, in order to have the analytic entries, you must first indicate the > analytic account on the "originator" document. Hence, whenever there is a > new module, you may want to add an analytic account. e.g. stock_request, or > purchase_request etc.. > or whatever module you are building: > subscription, contract, team etc... > > Regards, > Dominique > > On Mon, 12 Oct 2020 at 17:38, Radovan Skolnik <radovan@skolnik.info> wrote: > > Great! Thank you very much Dominique. > > > > One more question: as I explained before I want to use this to produce > > account.analytic.line records to get costs and revenues of cases / > > project. I > > see lots of modules in OCA/account-analytic that allow adding analytic > > account > > info to various objects. What is the general idea on using this > > information? > > Is it creation of those account.analytic.line - i.e. Analytic Items? If > > so, > > how are they generated? Or am I missing something here? > > > > Best regards > > > > Radovan > > > > On pondelok 12. októbra 2020 11:32:38 CEST Dominique k wrote: > > > indeed. We added few lines of code to propagate the analytic account > > > > from SO > > > > > to stock move. Not sure why it is not a module in OCA. May be because it > > > > is > > > > > very small, and has to rely on a "glue" module ('sale_stock') Anyway, if > > > you add this (v13), in your code, it would work. (you also need to add a > > > dependency to 'sale_stock' in your manifest class > > > SaleOrderLine(models.Model): > > > _inherit = 'sale.order.line' > > > def _prepare_procurement_values(self, group_id=False): > > > res = super(SaleOrderLine, > > > self)._prepare_procurement_values(group_id=group_id) analytic_id = > > > self.order_id.analytic_account_id > > > res['analytic_account_id'] = analytic_id and analytic_id.id [1] or False > > > return res > > > > > > class StockRule(models.Model): > > > _inherit = 'stock.rule' > > > def _get_custom_move_fields(self): > > > fields = super(StockRule, self)._get_custom_move_fields() > > > fields += ['analytic_account_id'] > > > return fields > > > Regards, Dominique > > > On Mon, 12 Oct 2020 at 16:57, Radovan Skolnik < radovan@skolnik.info > > > > [2] > > > > > > wrote: Aaron, > > > I cannot seem to get analytic_account_id propagated from SO to outgoing > > > stock moves (also from PO to incoming stock moves). Is that supposed to > > > work that way? When PO is created from SO the value is propagated there > > > though. Best regards > > > Radovan > > > > > > On štvrtok 8. októbra 2020 17:52:24 CEST Aarón Henríquez Quintana wrote: > > > > Yes, sorry for that. It only creates analytic entries if you use real > > > > time > > > > > > inventory valuation. Regards. > > > > On Thu, 8 Oct 2020 at 13:52, Radovan Skolnik < radovan@skolnik.info > > > > [3] > > > > > > [1] > wrote: Thanx Aaron for info. But do I understand it correctly > > > > that > > > > > > this only propagates analytic account value into different objects but > > > > does not create account.analytic.line records? I need to get cost of > > > > products into them as negative amounts to be able to calulate > > > > profitability of analytic account. Best regards > > > > Radovan > > > > > > > > On štvrtok 8. októbra 2020 10:42:06 CEST Aarón Henríquez Quintana > > > > wrote: > > > > > Yes. It is possible. You need a couple of modules: > > > > > https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [4] [2] [1] > > > > > adds the> > > > > > > > > > > > analytic account to the stock move. > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_sto > > > > > > > ck [5]> > > > > > > > > > > > _a [3]> > > > > > nalytic [2] I use this for passing the analytic form the PO lines to > > > > the > > > > > > > stock moves. I think there is a similar one in the OCA apps but I > > > > don't > > > > > > > remember what it is called. > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analy > > > > > > > ti [6]> > > > > > > > > > > > c [4]> > > > > > [3] To pass the analytic information from the SO to the stock moves > > > > of > > > > > > > the > > > > > delivery. Regards. > > > > > On Thu, 8 Oct 2020 at 10:17, Radovan Skolnik < radovan@skolnik.info > > > > [7] > > > > > > > [5] [4] > wrote: Hello, > > > > > we would like to use analytic accounts to track profitability of > > > > > individual > > > > > sales. So I'd setup automatic creation of analytic account on > > > > confirmed > > > > > > > sale orders which would be propagated to invoices. This would cover > > > > the > > > > > > > credit side. What I am struggling with is the debit side - i.e. > > > > costs of > > > > > > > products. One way would be adding analytic account on POs/POLs but > > > > that > > > > > > > is not feasible because we can have products in stock from past > > > > which we > > > > > > > decide to sell. So my idea is to generate account.analytic.line > > > > records > > > > > > > from stock.moves and assign them value according to average value. > > > > Are > > > > > > > there any modules that would support this? Or should I choose > > > > different > > > > > > > approach? Thank you. Best regards > > > > > Radovan Skolnik > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > > [8] [6] > > > > > > > [5] Post to: mailto: contributors@odoo-community.org [9] [7] [6] > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [10] > > > > [8] [7] > > > > > > > _______________________________________________ > > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > > [11] > > > > > > > [9] [8] Post to: mailto: contributors@odoo-community.org [12] [10] > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [13] > > > > [11] > > > > > > > [9] > > > > > > > > > > > > > > > > > > > > [1] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [14] > > > > [12] > > > > > > > [2] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_sto > > > > > > > ck [15]> > > > > > > > > > > > _a [13]> > > > > > nalytic [3] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analy > > > > > > > ti [16]> > > > > > > > > > > > c [14]> > > > > > [4] mailto: radovan@skolnik.info [17] [15] > > > > > [5] https://odoo-community.org/groups/contributors-15 [18] [16] > > > > > [6] mailto: contributors@odoo-community.org [19] [17] > > > > > [7] https://odoo-community.org/groups?unsubscribe [20] [18] > > > > > [8] https://odoo-community.org/groups/contributors-15 [21] [19] > > > > > [9] https://odoo-community.org/groups?unsubscribe [22] [20] > > > > > > > > _______________________________________________ > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [23] > > > > [21] > > > > > > Post to: mailto: contributors@odoo-community.org [24] [22] > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [25] [23] > > > > > > > > > > > > _______________________________________________ > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [26] > > > > [24] > > > > > > Post to: mailto: contributors@odoo-community.org [27] > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [28] [25] > > > > > > > > > > > > > > > > [1] mailto: radovan@skolnik.info [29] > > > > [2] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [30] > > > > [3] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > > > > > _a [31]> > > > > > > > > [4] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > > > > > c [32]> > > > > > > > > [5] mailto: radovan@skolnik.info [33] > > > > [6] https://odoo-community.org/groups/contributors-15 [34] > > > > [7] mailto: contributors@odoo-community.org [35] > > > > [8] https://odoo-community.org/groups?unsubscribe [36] > > > > [9] https://odoo-community.org/groups/contributors-15 [37] > > > > [10] mailto: contributors@odoo-community.org [38] > > > > [11] https://odoo-community.org/groups?unsubscribe [39] > > > > [12] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [40] > > > > [13] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > > > > > _a [41]> > > > > > > > > [14] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > > > > > c [42]> > > > > > > > > [15] mailto: radovan@skolnik.info [43] > > > > [16] https://odoo-community.org/groups/contributors-15 [44] > > > > [17] mailto: contributors@odoo-community.org [45] > > > > [18] https://odoo-community.org/groups?unsubscribe [46] > > > > [19] https://odoo-community.org/groups/contributors-15 [47] > > > > [20] https://odoo-community.org/groups?unsubscribe [48] > > > > [21] https://odoo-community.org/groups/contributors-15 [49] > > > > [22] mailto: contributors@odoo-community.org [50] > > > > [23] https://odoo-community.org/groups?unsubscribe [51] > > > > [24] https://odoo-community.org/groups/contributors-15 [52] > > > > [25] https://odoo-community.org/groups?unsubscribe [53] > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [54] > > > Post to: mailto: contributors@odoo-community.org [55] > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [56] > > > > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [57] > > > Post to: mailto:contributors@odoo-community.org > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [58] > > > > > > > > > > > > [1] http://analytic_id.id > > > [2] mailto:radovan@skolnik.info > > > [3] mailto:radovan@skolnik.info > > > [4] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > > > [5] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > > > > [6] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > > > > [7] mailto:radovan@skolnik.info > > > [8] https://odoo-community.org/groups/contributors-15 > > > [9] mailto:contributors@odoo-community.org > > > [10] https://odoo-community.org/groups?unsubscribe > > > [11] https://odoo-community.org/groups/contributors-15 > > > [12] mailto:contributors@odoo-community.org > > > [13] https://odoo-community.org/groups?unsubscribe > > > [14] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > > > [15] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > > > > [16] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > > > > [17] mailto:radovan@skolnik.info > > > [18] https://odoo-community.org/groups/contributors-15 > > > [19] mailto:contributors@odoo-community.org > > > [20] https://odoo-community.org/groups?unsubscribe > > > [21] https://odoo-community.org/groups/contributors-15 > > > [22] https://odoo-community.org/groups?unsubscribe > > > [23] https://odoo-community.org/groups/contributors-15 > > > [24] mailto:contributors@odoo-community.org > > > [25] https://odoo-community.org/groups?unsubscribe > > > [26] https://odoo-community.org/groups/contributors-15 > > > [27] mailto:contributors@odoo-community.org > > > [28] https://odoo-community.org/groups?unsubscribe > > > [29] mailto:radovan@skolnik.info > > > [30] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > > > [31] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_ > > a > > > > > [32] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic > > > > > [33] mailto:radovan@skolnik.info > > > [34] https://odoo-community.org/groups/contributors-15 > > > [35] mailto:contributors@odoo-community.org > > > [36] https://odoo-community.org/groups?unsubscribe > > > [37] https://odoo-community.org/groups/contributors-15 > > > [38] mailto:contributors@odoo-community.org > > > [39] https://odoo-community.org/groups?unsubscribe > > > [40] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > > > [41] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_ > > a > > > > > [42] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic > > > > > [43] mailto:radovan@skolnik.info > > > [44] https://odoo-community.org/groups/contributors-15 > > > [45] mailto:contributors@odoo-community.org > > > [46] https://odoo-community.org/groups?unsubscribe > > > [47] https://odoo-community.org/groups/contributors-15 > > > [48] https://odoo-community.org/groups?unsubscribe > > > [49] https://odoo-community.org/groups/contributors-15 > > > [50] mailto:contributors@odoo-community.org > > > [51] https://odoo-community.org/groups?unsubscribe > > > [52] https://odoo-community.org/groups/contributors-15 > > > [53] https://odoo-community.org/groups?unsubscribe > > > [54] https://odoo-community.org/groups/contributors-15 > > > [55] mailto:contributors@odoo-community.org > > > [56] https://odoo-community.org/groups?unsubscribe > > > [57] https://odoo-community.org/groups/contributors-15 > > > [58] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 12:11 - 12 Oct 2020 -
Re: 14.0 branches
Hello Laurent and all.El lun., 12 de oct. de 2020 a la(s) 02:07, Mignon, Laurent (laurent.mignon@acsone.eu) escribió:HI Folks,I think it's very important to keep the debate open and to present your arguments in a constructive way.I must admit that I am a little saddened to read accusations of half-truths when the process is meant to be open and constructive. It seems to me that the goal here is not to impose a new methodology but to confront our practices with those of the python community.Me too!But I think what we are having now is a "coup d'etat" and nobody in charge is answering (at least what I see) the questions.I want and will be Open and argumenting constructively, but to be fairly honest, 3 things are clear for me we can not do with pip (and I am not moving forward until those are not solved and the reasons all was born, I can not be constructive when somebody come to brake everything is built even with the best of the intentions).1.- No SHA management present in PIP linked with git (or if it is an extra layer BTW).2.- No Oca dependencies (remember it is not optional nor auto done, We need to have one and only one place where to say technically where is my dependency code) , which means if PIP consume oca_dependencies then nice, but not make us to re-create all into PIP and then auto create a oca_dependency.txtI have an honest question:Do you think Odoo will be pip-installable in some moment?I see communities like tryton and plone that claim be so so so pip lovers and python perfectionists, and I personally have FAST way to consume (with PIP) but **really complex way** to contribute, because PIP is a tool to improve the **pull** process not the **push** process.Why do we insist on changing all to PIP when we have a flow that works!? and in fact, each time I take a customer that deploys with PIP they have a perfect mess, nobody knows anything about nothing.The fact that the aim of this approach is to simplify the maintenance of our OCA repositories as well as to reduce the learning curve for new developers, I find this more than remarkable and valuable.
Since many integrators' tools/processes are now based on the oca_dependencies.txt and requirement.txt files, in view of the discussion it seems necessary that somehow these should be available again. It seems to me that automating the generation of these files would be more than beneficial because it would avoid inconsistencies in the future for all the processes based on them.I need to say man to be honest, there is no proof that if we change to PIP more people will contribute (there is non a single proof this will happen), In fact I think it will increase the consumption of modules but it will decrease the actual contribution.Why?Because you are separating process from develop-deploy-consume on different tools then this will be impossible to use the same effort to contribute and people with come down with the contribution.
Over the years I have used different tools and methodologies to try to improve the management of our dev -> prod processes of our python projects. I personally contributed to buildout, imagined and wrote git-agggregator, .... The goal has always been to improve the traceability and reproducibility of our developments and deployments. Today, and thanks to the evolutions around pip, I'm happy to see that python tools allow me to improve and simplify these processes without having to use specific tools. (While bringing more freedom and features).And me too!But what I do not know how to explain myself and it looks like I am alone on this battle is:PIP is not a tool to **contribute** with the code but to **distribute** the code.Then, it will not improve the collaboration, it will increase (and it is nice) the consumption of the software, but say that other pythonists will come easier because PIP is not true.IMHO this should be the approach (as any other package).code -> oca_dependencies > download dependencies -> test packages IF Ok then generate the new version for a pIP package test the PIP package and END.What I understand (and please correct me if I am wrong) is that you want to start to maintain PIP packages and ignore completely the current approach, and I can't find a way or a single reason why loose the flexibility that a single file gives us (the opca_dependencies) as centralizer.Note: I am pretty sure the current mechanism has other issues but that in particular for me is the no-go topic.
Is it possible to envisage an evolution of our integration mechanisms towards pip support while retaining the necessary elements for the other approaches developed by the various parties?I am IN but not on this way, let's at least make a plan together and inform a proper time (not overnight when a version which almost all modules will work from the old one was just released).
I find it motivating to confront this approach with all the use cases of each other in order to determine the limits of this approach. This will at least allow us to improve our knowledge and perhaps correct certain ideas.Me too!RegardsI ask for apologize If I am being rude, but I can't find other ways to be clear/plain and simple about my point.Regards.On Mon, Oct 12, 2020 at 12:11 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:El dom., 11 de oct. de 2020 a la(s) 12:17, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:As said, my only goal is to improve the OCA contribution workflow.Of course, I don't want to force any specific installation method onto integrators workflows.Sorry my friend, but if you continue insists that the Integration, deployment and testing are separated and differently managed, then you are doing and proposing exactly the opposite here.Everybody should deploy/test/use the software in the same unique way (the only difference should be the extra dependencies required for the testing environment itself that are not required in production, and even this can be used in production as well but some prefer not doing it.So let's try to keep the discussion focused.To be a little bit more specific, here are some aspects that the new method improves:Less RedundancyWhat is in requirements.txt must be added manually and is redundant to addons manifests. oca_dependencies.txt is also redundant and the information can be found elsewhere.Why oca_dependencies is redundant? currently, Where else I can find that information?
Better testing of dependency declarations
We don't test external python dependencies declarations in manifests because we rely on a redundant, manually maintained requirements.txtWith PIP this will happen too! (that's the problem with the pip-hell that I linked my friend).pylint-odoo helps but there are limits to what it can detect.The same in the other way around, pylint-odoo was born because we need to test things that need odoo running and/or a very specific odoo environment.
Also, we publish wheels for OCA addons because it is by far the easiest for newcomers (and veterans alike I should say) to discover dependencies (addons and external python dependencies). Bad dependencies makes for a suboptimal user experience for newcomers installing the wheels.I think the opposite here, (I am a veteran python consumir as you are, and honestly I prefer 100% read how to deploy odoo than deal with pip-hell).But in this case you get a point which is the newcomers we should teach more and document better the current process, not remove features for them (it is dangerous in the long term).
Reduced blast radius when addons are introduced with specific test requirements, or "exotic" test requirements break
When an addon has specific test requirements it has side effects in all repos that transitively depend on its repo, whether or not the modules are actually needed. When installing dependencies at the addon level instead of the repo level, we drastically reduce the blast radius of such things. Examples: server_environment that required a mandatory option in odoo.cfg. Or an obscure dependency of some rarely used addon in server-tools that suddenly breaks on PyPI and impacts all repos that transitively depend on server-tools because they all end up installing all requirements.txt of server-tools. When that happens, the impact is usually so wide that everyone has to rush to find solutions to unlock the situation. If the impact is contained to the addon and those that depend on it, that buys us more time to find good solutions.But this is only solved if we move the dependencies (the current one) to module level, not change all to PIP.On the other hand, you get a point!, solution: Avoid tools that change the odoo.cfg modification as a good practice, but that's another story..Finer grained approach to declaring unmerged dependenciesWith the optional test-requirements.txt, you can declare override dependencies to target unmerged individual addons like this:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}WAO:How i that simplest that say:folder git@url/repo branch ?This means you can reference several PRs of the same repos, or several addons of different PRs in another repo (I don't think one can do that with oca_dependencies.txt, where you reference whole repos).Same as above.[BTW, @Moises, to answer your question above you could use such references to your own repos. And it reduces the need to use git-aggregator too. - but I digress]To close the list, I'd say dependency management is hard and relying on the broader python ecosystem to solve the problem can only help us in the long run (pip in particular is going to release a new sophisticated dependency resolver later this year).I think we should wait for that, I have 5 years hearing this will happen from Python Foundation and it is more complicated than ever with the expansion of python. By that time we should wait for that PEP and understanding it before move all.And Odoo is not particularly messy nor does it have anything very special in that matter.So how can we progress?For the reasons above, I'd like to move out of the status quo.In the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete.From me you received the same arguments I am giving here... it is not that simple, I am fully worried, you are saying half/truths here, almost all the arguments are incomplete.But that's another topic here.So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback.Solid feedback:Let's use pip BUT the old way too, until the PIP is stable and we can seriously have something solid.I am fully worried, we end up with a Frank-PIP as well which will return us to the same point we are today but with PIP.Your half/true statements to be fairly honest, shows that neither you or us will agree because neither we want to deal with PIP-hell until Odoo supports it, and you are not working with the current status Quo.I think the blocking point is ther.No harm is done (there are no cross-repo dependencies in v14 branches yet :) and as said, we can easily push an update to .travis.yml.No man, there is.We are deploying v14 since 4 month ago.We have even saas-XX repos preparing thing to be migrated.Tis is not something that must be done in September pre-experience.Let' s work for version 15 from now on (or even 16) to prepare the future.With the new fast migration strategy in Odoo, we can not make this change now, for december we will have a ton of migrated databases and left OCA behind too much.
And the good thing is that the feedback is coming:- At this point I see Moises who says it relies on oca_dependencies.txt in its workflow.- Daniel mentioned a documentation value of oca_dependencies.txt.A few questions:- @Moises, do you rely on requirement.txt too in your own workflow ?Yes, we do.- Do others rely on it ? (for instance, does Dooba need oca_dependencies.txt, requirements.txt in OCA repos ?)Yes, we do!
If we conclude that oca_dependencies.txt and/or requirements.txt must be preserved in all repos in v14 (and I'm totally fine with that), we can then discuss how best to do it.Not just preserve it (it is not a matter of have a file man, please I ask you to not oversimplify this) All the CI is and will rely on such files too!, if not you are forcing people to re-write such information in a dummy file (PIP-s way) please..Either manual with e.g. PIP mode on Odoo and OCA mode on OCB as Moises suggested - but that would be a burden for contributors to understand and maintain both approaches. Or try to generate oca_dependencies.txt and requirements.txt, which should be feasible at first sight, but that's more work. Or keep the status quo :/The easiest way is if you update your workflow instead try to change the current one to something that will left all incomplete....But again on my side I think or both or the current one.
Cheers,-sbiregards!On Sun, Oct 11, 2020 at 7:06 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.-sbi_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 12:05 - 12 Oct 2020 -
Re: Is there a way to create account.analytic.line from stock.move?
Great! Thank you very much Dominique. One more question: as I explained before I want to use this to produce account.analytic.line records to get costs and revenues of cases / project. I see lots of modules in OCA/account-analytic that allow adding analytic account info to various objects. What is the general idea on using this information? Is it creation of those account.analytic.line - i.e. Analytic Items? If so, how are they generated? Or am I missing something here? Best regards Radovan On pondelok 12. októbra 2020 11:32:38 CEST Dominique k wrote: > indeed. We added few lines of code to propagate the analytic account from SO > to stock move. Not sure why it is not a module in OCA. May be because it is > very small, and has to rely on a "glue" module ('sale_stock') Anyway, if > you add this (v13), in your code, it would work. (you also need to add a > dependency to 'sale_stock' in your manifest class > SaleOrderLine(models.Model): > _inherit = 'sale.order.line' > def _prepare_procurement_values(self, group_id=False): > res = super(SaleOrderLine, > self)._prepare_procurement_values(group_id=group_id) analytic_id = > self.order_id.analytic_account_id > res['analytic_account_id'] = analytic_id and analytic_id.id [1] or False > return res > > class StockRule(models.Model): > _inherit = 'stock.rule' > def _get_custom_move_fields(self): > fields = super(StockRule, self)._get_custom_move_fields() > fields += ['analytic_account_id'] > return fields > Regards, Dominique > On Mon, 12 Oct 2020 at 16:57, Radovan Skolnik < radovan@skolnik.info [2] > > wrote: Aaron, > I cannot seem to get analytic_account_id propagated from SO to outgoing > stock moves (also from PO to incoming stock moves). Is that supposed to > work that way? When PO is created from SO the value is propagated there > though. Best regards > Radovan > > On štvrtok 8. októbra 2020 17:52:24 CEST Aarón Henríquez Quintana wrote: > > Yes, sorry for that. It only creates analytic entries if you use real time > > inventory valuation. Regards. > > On Thu, 8 Oct 2020 at 13:52, Radovan Skolnik < radovan@skolnik.info [3] > > [1] > wrote: Thanx Aaron for info. But do I understand it correctly that > > this only propagates analytic account value into different objects but > > does not create account.analytic.line records? I need to get cost of > > products into them as negative amounts to be able to calulate > > profitability of analytic account. Best regards > > Radovan > > > > On štvrtok 8. októbra 2020 10:42:06 CEST Aarón Henríquez Quintana wrote: > > > Yes. It is possible. You need a couple of modules: > > > https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [4] [2] [1] > > > adds the> > > > > analytic account to the stock move. > > > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_sto > > > ck [5]> > > > > _a [3]> > > > nalytic [2] I use this for passing the analytic form the PO lines to the > > > stock moves. I think there is a similar one in the OCA apps but I don't > > > remember what it is called. > > > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analy > > > ti [6]> > > > > c [4]> > > > [3] To pass the analytic information from the SO to the stock moves of > > > the > > > delivery. Regards. > > > On Thu, 8 Oct 2020 at 10:17, Radovan Skolnik < radovan@skolnik.info [7] > > > [5] [4] > wrote: Hello, > > > we would like to use analytic accounts to track profitability of > > > individual > > > sales. So I'd setup automatic creation of analytic account on confirmed > > > sale orders which would be propagated to invoices. This would cover the > > > credit side. What I am struggling with is the debit side - i.e. costs of > > > products. One way would be adding analytic account on POs/POLs but that > > > is not feasible because we can have products in stock from past which we > > > decide to sell. So my idea is to generate account.analytic.line records > > > from stock.moves and assign them value according to average value. Are > > > there any modules that would support this? Or should I choose different > > > approach? Thank you. Best regards > > > Radovan Skolnik > > > > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [8] [6] > > > [5] Post to: mailto: contributors@odoo-community.org [9] [7] [6] > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [10] [8] [7] > > > > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [11] > > > [9] [8] Post to: mailto: contributors@odoo-community.org [12] [10] > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [13] [11] > > > [9] > > > > > > > > > > > > [1] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [14] [12] > > > [2] > > > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_sto > > > ck [15]> > > > > _a [13]> > > > nalytic [3] > > > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analy > > > ti [16]> > > > > c [14]> > > > [4] mailto: radovan@skolnik.info [17] [15] > > > [5] https://odoo-community.org/groups/contributors-15 [18] [16] > > > [6] mailto: contributors@odoo-community.org [19] [17] > > > [7] https://odoo-community.org/groups?unsubscribe [20] [18] > > > [8] https://odoo-community.org/groups/contributors-15 [21] [19] > > > [9] https://odoo-community.org/groups?unsubscribe [22] [20] > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [23] [21] > > Post to: mailto: contributors@odoo-community.org [24] [22] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [25] [23] > > > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [26] [24] > > Post to: mailto: contributors@odoo-community.org [27] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [28] [25] > > > > > > > > [1] mailto: radovan@skolnik.info [29] > > [2] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [30] > > [3] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > _a [31]> > > [4] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > c [32]> > > [5] mailto: radovan@skolnik.info [33] > > [6] https://odoo-community.org/groups/contributors-15 [34] > > [7] mailto: contributors@odoo-community.org [35] > > [8] https://odoo-community.org/groups?unsubscribe [36] > > [9] https://odoo-community.org/groups/contributors-15 [37] > > [10] mailto: contributors@odoo-community.org [38] > > [11] https://odoo-community.org/groups?unsubscribe [39] > > [12] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [40] > > [13] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > _a [41]> > > [14] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > c [42]> > > [15] mailto: radovan@skolnik.info [43] > > [16] https://odoo-community.org/groups/contributors-15 [44] > > [17] mailto: contributors@odoo-community.org [45] > > [18] https://odoo-community.org/groups?unsubscribe [46] > > [19] https://odoo-community.org/groups/contributors-15 [47] > > [20] https://odoo-community.org/groups?unsubscribe [48] > > [21] https://odoo-community.org/groups/contributors-15 [49] > > [22] mailto: contributors@odoo-community.org [50] > > [23] https://odoo-community.org/groups?unsubscribe [51] > > [24] https://odoo-community.org/groups/contributors-15 [52] > > [25] https://odoo-community.org/groups?unsubscribe [53] > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [54] > Post to: mailto: contributors@odoo-community.org [55] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [56] > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [57] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [58] > > > > [1] http://analytic_id.id > [2] mailto:radovan@skolnik.info > [3] mailto:radovan@skolnik.info > [4] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > [5] > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > [6] > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > [7] mailto:radovan@skolnik.info > [8] https://odoo-community.org/groups/contributors-15 > [9] mailto:contributors@odoo-community.org > [10] https://odoo-community.org/groups?unsubscribe > [11] https://odoo-community.org/groups/contributors-15 > [12] mailto:contributors@odoo-community.org > [13] https://odoo-community.org/groups?unsubscribe > [14] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > [15] > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > [16] > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > [17] mailto:radovan@skolnik.info > [18] https://odoo-community.org/groups/contributors-15 > [19] mailto:contributors@odoo-community.org > [20] https://odoo-community.org/groups?unsubscribe > [21] https://odoo-community.org/groups/contributors-15 > [22] https://odoo-community.org/groups?unsubscribe > [23] https://odoo-community.org/groups/contributors-15 > [24] mailto:contributors@odoo-community.org > [25] https://odoo-community.org/groups?unsubscribe > [26] https://odoo-community.org/groups/contributors-15 > [27] mailto:contributors@odoo-community.org > [28] https://odoo-community.org/groups?unsubscribe > [29] mailto:radovan@skolnik.info > [30] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > [31] > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_a > [32] > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic > [33] mailto:radovan@skolnik.info > [34] https://odoo-community.org/groups/contributors-15 > [35] mailto:contributors@odoo-community.org > [36] https://odoo-community.org/groups?unsubscribe > [37] https://odoo-community.org/groups/contributors-15 > [38] mailto:contributors@odoo-community.org > [39] https://odoo-community.org/groups?unsubscribe > [40] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > [41] > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_a > [42] > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic > [43] mailto:radovan@skolnik.info > [44] https://odoo-community.org/groups/contributors-15 > [45] mailto:contributors@odoo-community.org > [46] https://odoo-community.org/groups?unsubscribe > [47] https://odoo-community.org/groups/contributors-15 > [48] https://odoo-community.org/groups?unsubscribe > [49] https://odoo-community.org/groups/contributors-15 > [50] mailto:contributors@odoo-community.org > [51] https://odoo-community.org/groups?unsubscribe > [52] https://odoo-community.org/groups/contributors-15 > [53] https://odoo-community.org/groups?unsubscribe > [54] https://odoo-community.org/groups/contributors-15 > [55] mailto:contributors@odoo-community.org > [56] https://odoo-community.org/groups?unsubscribe > [57] https://odoo-community.org/groups/contributors-15 > [58] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 11:40 - 12 Oct 2020 -
Re: Is there a way to create account.analytic.line from stock.move?
Aaron, I cannot seem to get analytic_account_id propagated from SO to outgoing stock moves (also from PO to incoming stock moves). Is that supposed to work that way? When PO is created from SO the value is propagated there though. Best regards Radovan On štvrtok 8. októbra 2020 17:52:24 CEST Aarón Henríquez Quintana wrote: > Yes, sorry for that. It only creates analytic entries if you use real time > inventory valuation. Regards. > On Thu, 8 Oct 2020 at 13:52, Radovan Skolnik < radovan@skolnik.info [1] > > wrote: Thanx Aaron for info. But do I understand it correctly that this > only propagates analytic account value into different objects but does not > create account.analytic.line records? I need to get cost of products into > them as negative amounts to be able to calulate profitability of analytic > account. Best regards > Radovan > > On štvrtok 8. októbra 2020 10:42:06 CEST Aarón Henríquez Quintana wrote: > > Yes. It is possible. You need a couple of modules: > > https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [2] [1] adds the > > > > analytic account to the stock move. > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > _a [3]> > > nalytic [2] I use this for passing the analytic form the PO lines to the > > stock moves. I think there is a similar one in the OCA apps but I don't > > remember what it is called. > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > c [4]> > > [3] To pass the analytic information from the SO to the stock moves of the > > delivery. Regards. > > On Thu, 8 Oct 2020 at 10:17, Radovan Skolnik < radovan@skolnik.info [5] > > [4] > wrote: Hello, > > we would like to use analytic accounts to track profitability of > > individual > > sales. So I'd setup automatic creation of analytic account on confirmed > > sale orders which would be propagated to invoices. This would cover the > > credit side. What I am struggling with is the debit side - i.e. costs of > > products. One way would be adding analytic account on POs/POLs but that > > is not feasible because we can have products in stock from past which we > > decide to sell. So my idea is to generate account.analytic.line records > > from stock.moves and assign them value according to average value. Are > > there any modules that would support this? Or should I choose different > > approach? Thank you. Best regards > > Radovan Skolnik > > > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [6] [5] > > Post to: mailto: contributors@odoo-community.org [7] [6] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [8] [7] > > > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [9] [8] > > Post to: mailto: contributors@odoo-community.org [10] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [11] [9] > > > > > > > > [1] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ [12] > > [2] > > > > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock > > _a [13]> > > nalytic [3] > > > > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analyti > > c [14]> > > [4] mailto: radovan@skolnik.info [15] > > [5] https://odoo-community.org/groups/contributors-15 [16] > > [6] mailto: contributors@odoo-community.org [17] > > [7] https://odoo-community.org/groups?unsubscribe [18] > > [8] https://odoo-community.org/groups/contributors-15 [19] > > [9] https://odoo-community.org/groups?unsubscribe [20] > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [21] > Post to: mailto: contributors@odoo-community.org [22] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [23] > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [24] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [25] > > > > [1] mailto:radovan@skolnik.info > [2] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > [3] > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_a > [4] > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic > [5] mailto:radovan@skolnik.info > [6] https://odoo-community.org/groups/contributors-15 > [7] mailto:contributors@odoo-community.org > [8] https://odoo-community.org/groups?unsubscribe > [9] https://odoo-community.org/groups/contributors-15 > [10] mailto:contributors@odoo-community.org > [11] https://odoo-community.org/groups?unsubscribe > [12] https://apps.odoo.com/apps/modules/12.0/stock_analytic/ > [13] > https://github.com/ForgeFlow/eficent-odoo-addons/tree/12.0/purchase_stock_a > [14] > https://github.com/OCA/account-analytic/tree/12.0/procurement_mto_analytic > [15] mailto:radovan@skolnik.info > [16] https://odoo-community.org/groups/contributors-15 > [17] mailto:contributors@odoo-community.org > [18] https://odoo-community.org/groups?unsubscribe > [19] https://odoo-community.org/groups/contributors-15 > [20] https://odoo-community.org/groups?unsubscribe > [21] https://odoo-community.org/groups/contributors-15 > [22] mailto:contributors@odoo-community.org > [23] https://odoo-community.org/groups?unsubscribe > [24] https://odoo-community.org/groups/contributors-15 > [25] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 10:56 - 12 Oct 2020 -
Re: 14.0 branches
HI Folks,I think it's very important to keep the debate open and to present your arguments in a constructive way.I must admit that I am a little saddened to read accusations of half-truths when the process is meant to be open and constructive. It seems to me that the goal here is not to impose a new methodology but to confront our practices with those of the python community. The fact that the aim of this approach is to simplify the maintenance of our OCA repositories as well as to reduce the learning curve for new developers, I find this more than remarkable and valuable.
Since many integrators' tools/processes are now based on the oca_dependencies.txt and requirement.txt files, in view of the discussion it seems necessary that somehow these should be available again. It seems to me that automating the generation of these files would be more than beneficial because it would avoid inconsistencies in the future for all the processes based on them.
Over the years I have used different tools and methodologies to try to improve the management of our dev -> prod processes of our python projects. I personally contributed to buildout, imagined and wrote git-agggregator, .... The goal has always been to improve the traceability and reproducibility of our developments and deployments. Today, and thanks to the evolutions around pip, I'm happy to see that python tools allow me to improve and simplify these processes without having to use specific tools. (While bringing more freedom and features).
Is it possible to envisage an evolution of our integration mechanisms towards pip support while retaining the necessary elements for the other approaches developed by the various parties?
I find it motivating to confront this approach with all the use cases of each other in order to determine the limits of this approach. This will at least allow us to improve our knowledge and perhaps correct certain ideas.RegardsOn Mon, Oct 12, 2020 at 12:11 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:El dom., 11 de oct. de 2020 a la(s) 12:17, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:As said, my only goal is to improve the OCA contribution workflow.Of course, I don't want to force any specific installation method onto integrators workflows.Sorry my friend, but if you continue insists that the Integration, deployment and testing are separated and differently managed, then you are doing and proposing exactly the opposite here.Everybody should deploy/test/use the software in the same unique way (the only difference should be the extra dependencies required for the testing environment itself that are not required in production, and even this can be used in production as well but some prefer not doing it.So let's try to keep the discussion focused.To be a little bit more specific, here are some aspects that the new method improves:Less RedundancyWhat is in requirements.txt must be added manually and is redundant to addons manifests. oca_dependencies.txt is also redundant and the information can be found elsewhere.Why oca_dependencies is redundant? currently, Where else I can find that information?
Better testing of dependency declarations
We don't test external python dependencies declarations in manifests because we rely on a redundant, manually maintained requirements.txtWith PIP this will happen too! (that's the problem with the pip-hell that I linked my friend).pylint-odoo helps but there are limits to what it can detect.The same in the other way around, pylint-odoo was born because we need to test things that need odoo running and/or a very specific odoo environment.
Also, we publish wheels for OCA addons because it is by far the easiest for newcomers (and veterans alike I should say) to discover dependencies (addons and external python dependencies). Bad dependencies makes for a suboptimal user experience for newcomers installing the wheels.I think the opposite here, (I am a veteran python consumir as you are, and honestly I prefer 100% read how to deploy odoo than deal with pip-hell).But in this case you get a point which is the newcomers we should teach more and document better the current process, not remove features for them (it is dangerous in the long term).
Reduced blast radius when addons are introduced with specific test requirements, or "exotic" test requirements break
When an addon has specific test requirements it has side effects in all repos that transitively depend on its repo, whether or not the modules are actually needed. When installing dependencies at the addon level instead of the repo level, we drastically reduce the blast radius of such things. Examples: server_environment that required a mandatory option in odoo.cfg. Or an obscure dependency of some rarely used addon in server-tools that suddenly breaks on PyPI and impacts all repos that transitively depend on server-tools because they all end up installing all requirements.txt of server-tools. When that happens, the impact is usually so wide that everyone has to rush to find solutions to unlock the situation. If the impact is contained to the addon and those that depend on it, that buys us more time to find good solutions.But this is only solved if we move the dependencies (the current one) to module level, not change all to PIP.On the other hand, you get a point!, solution: Avoid tools that change the odoo.cfg modification as a good practice, but that's another story..Finer grained approach to declaring unmerged dependenciesWith the optional test-requirements.txt, you can declare override dependencies to target unmerged individual addons like this:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}WAO:How i that simplest that say:folder git@url/repo branch ?This means you can reference several PRs of the same repos, or several addons of different PRs in another repo (I don't think one can do that with oca_dependencies.txt, where you reference whole repos).Same as above.[BTW, @Moises, to answer your question above you could use such references to your own repos. And it reduces the need to use git-aggregator too. - but I digress]To close the list, I'd say dependency management is hard and relying on the broader python ecosystem to solve the problem can only help us in the long run (pip in particular is going to release a new sophisticated dependency resolver later this year).I think we should wait for that, I have 5 years hearing this will happen from Python Foundation and it is more complicated than ever with the expansion of python. By that time we should wait for that PEP and understanding it before move all.And Odoo is not particularly messy nor does it have anything very special in that matter.So how can we progress?For the reasons above, I'd like to move out of the status quo.In the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete.From me you received the same arguments I am giving here... it is not that simple, I am fully worried, you are saying half/truths here, almost all the arguments are incomplete.But that's another topic here.So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback.Solid feedback:Let's use pip BUT the old way too, until the PIP is stable and we can seriously have something solid.I am fully worried, we end up with a Frank-PIP as well which will return us to the same point we are today but with PIP.Your half/true statements to be fairly honest, shows that neither you or us will agree because neither we want to deal with PIP-hell until Odoo supports it, and you are not working with the current status Quo.I think the blocking point is ther.No harm is done (there are no cross-repo dependencies in v14 branches yet :) and as said, we can easily push an update to .travis.yml.No man, there is.We are deploying v14 since 4 month ago.We have even saas-XX repos preparing thing to be migrated.Tis is not something that must be done in September pre-experience.Let' s work for version 15 from now on (or even 16) to prepare the future.With the new fast migration strategy in Odoo, we can not make this change now, for december we will have a ton of migrated databases and left OCA behind too much.
And the good thing is that the feedback is coming:- At this point I see Moises who says it relies on oca_dependencies.txt in its workflow.- Daniel mentioned a documentation value of oca_dependencies.txt.A few questions:- @Moises, do you rely on requirement.txt too in your own workflow ?Yes, we do.- Do others rely on it ? (for instance, does Dooba need oca_dependencies.txt, requirements.txt in OCA repos ?)Yes, we do!
If we conclude that oca_dependencies.txt and/or requirements.txt must be preserved in all repos in v14 (and I'm totally fine with that), we can then discuss how best to do it.Not just preserve it (it is not a matter of have a file man, please I ask you to not oversimplify this) All the CI is and will rely on such files too!, if not you are forcing people to re-write such information in a dummy file (PIP-s way) please..Either manual with e.g. PIP mode on Odoo and OCA mode on OCB as Moises suggested - but that would be a burden for contributors to understand and maintain both approaches. Or try to generate oca_dependencies.txt and requirements.txt, which should be feasible at first sight, but that's more work. Or keep the status quo :/The easiest way is if you update your workflow instead try to change the current one to something that will left all incomplete....But again on my side I think or both or the current one.
Cheers,-sbiregards!On Sun, Oct 11, 2020 at 7:06 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.-sbi_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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 - 09:05 - 12 Oct 2020 -
OCA - 2020 Delegates Campaign - Now Open
--
Dear Odoo enthusiasts, OCA members and contributors,The 2020 OCA Delegates Campaign is open. From now and until October 23rd 2020, you can apply as an OCA Delegate.
Why?
The Delegate Assembly is the Association’s supreme authority. Each Delegate member is entitled to one vote at the Delegate Assembly. Decisions of the Delegate Assembly are taken by a majority vote of the Delegate members present and voting. For further details, please read the Bylaws.
How?
To apply as a candidate, you have to:
sign the CLA (if not already done)
have a valid membership. Make sure to purchase your membership or renew it (you should have received the invoice for your renewal).
Campaign will be closed on October 23rd, 2020.
Then what?
The vote will be open from October 26th to November 6th, 2020. Current OCA Delegates will have to vote for 10 new Delegates among the candidates.
The results of the election will be announced on those lists on November 7th, 2020.
The 10 new Delegates will then take part with the existing Delegates in :
the 2020 OCA Board Member Campaign from November 9th to 20th, 2020
the 2020 OCA Financial Auditor Campaign from November 9th to 20th, 2020
the 2020 General Assembly from November 23rd to December 2nd, 2020.
Should you have any questions, please get in touch.
Warmest regards, Rebecca
Rebecca GellatlyGeneral SecretaryOdoo Community Association
by Rebecca Gellatly - 02:06 - 12 Oct 2020 -
Re: 14.0 branches
El dom., 11 de oct. de 2020 a la(s) 12:17, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:As said, my only goal is to improve the OCA contribution workflow.Of course, I don't want to force any specific installation method onto integrators workflows.Sorry my friend, but if you continue insists that the Integration, deployment and testing are separated and differently managed, then you are doing and proposing exactly the opposite here.Everybody should deploy/test/use the software in the same unique way (the only difference should be the extra dependencies required for the testing environment itself that are not required in production, and even this can be used in production as well but some prefer not doing it.So let's try to keep the discussion focused.To be a little bit more specific, here are some aspects that the new method improves:Less RedundancyWhat is in requirements.txt must be added manually and is redundant to addons manifests. oca_dependencies.txt is also redundant and the information can be found elsewhere.Why oca_dependencies is redundant? currently, Where else I can find that information?
Better testing of dependency declarations
We don't test external python dependencies declarations in manifests because we rely on a redundant, manually maintained requirements.txtWith PIP this will happen too! (that's the problem with the pip-hell that I linked my friend).pylint-odoo helps but there are limits to what it can detect.The same in the other way around, pylint-odoo was born because we need to test things that need odoo running and/or a very specific odoo environment.
Also, we publish wheels for OCA addons because it is by far the easiest for newcomers (and veterans alike I should say) to discover dependencies (addons and external python dependencies). Bad dependencies makes for a suboptimal user experience for newcomers installing the wheels.I think the opposite here, (I am a veteran python consumir as you are, and honestly I prefer 100% read how to deploy odoo than deal with pip-hell).But in this case you get a point which is the newcomers we should teach more and document better the current process, not remove features for them (it is dangerous in the long term).
Reduced blast radius when addons are introduced with specific test requirements, or "exotic" test requirements break
When an addon has specific test requirements it has side effects in all repos that transitively depend on its repo, whether or not the modules are actually needed. When installing dependencies at the addon level instead of the repo level, we drastically reduce the blast radius of such things. Examples: server_environment that required a mandatory option in odoo.cfg. Or an obscure dependency of some rarely used addon in server-tools that suddenly breaks on PyPI and impacts all repos that transitively depend on server-tools because they all end up installing all requirements.txt of server-tools. When that happens, the impact is usually so wide that everyone has to rush to find solutions to unlock the situation. If the impact is contained to the addon and those that depend on it, that buys us more time to find good solutions.But this is only solved if we move the dependencies (the current one) to module level, not change all to PIP.On the other hand, you get a point!, solution: Avoid tools that change the odoo.cfg modification as a good practice, but that's another story..Finer grained approach to declaring unmerged dependenciesWith the optional test-requirements.txt, you can declare override dependencies to target unmerged individual addons like this:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}WAO:How i that simplest that say:folder git@url/repo branch ?This means you can reference several PRs of the same repos, or several addons of different PRs in another repo (I don't think one can do that with oca_dependencies.txt, where you reference whole repos).Same as above.[BTW, @Moises, to answer your question above you could use such references to your own repos. And it reduces the need to use git-aggregator too. - but I digress]To close the list, I'd say dependency management is hard and relying on the broader python ecosystem to solve the problem can only help us in the long run (pip in particular is going to release a new sophisticated dependency resolver later this year).I think we should wait for that, I have 5 years hearing this will happen from Python Foundation and it is more complicated than ever with the expansion of python. By that time we should wait for that PEP and understanding it before move all.And Odoo is not particularly messy nor does it have anything very special in that matter.So how can we progress?For the reasons above, I'd like to move out of the status quo.In the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete.From me you received the same arguments I am giving here... it is not that simple, I am fully worried, you are saying half/truths here, almost all the arguments are incomplete.But that's another topic here.So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback.Solid feedback:Let's use pip BUT the old way too, until the PIP is stable and we can seriously have something solid.I am fully worried, we end up with a Frank-PIP as well which will return us to the same point we are today but with PIP.Your half/true statements to be fairly honest, shows that neither you or us will agree because neither we want to deal with PIP-hell until Odoo supports it, and you are not working with the current status Quo.I think the blocking point is ther.No harm is done (there are no cross-repo dependencies in v14 branches yet :) and as said, we can easily push an update to .travis.yml.No man, there is.We are deploying v14 since 4 month ago.We have even saas-XX repos preparing thing to be migrated.Tis is not something that must be done in September pre-experience.Let' s work for version 15 from now on (or even 16) to prepare the future.With the new fast migration strategy in Odoo, we can not make this change now, for december we will have a ton of migrated databases and left OCA behind too much.
And the good thing is that the feedback is coming:- At this point I see Moises who says it relies on oca_dependencies.txt in its workflow.- Daniel mentioned a documentation value of oca_dependencies.txt.A few questions:- @Moises, do you rely on requirement.txt too in your own workflow ?Yes, we do.- Do others rely on it ? (for instance, does Dooba need oca_dependencies.txt, requirements.txt in OCA repos ?)Yes, we do!
If we conclude that oca_dependencies.txt and/or requirements.txt must be preserved in all repos in v14 (and I'm totally fine with that), we can then discuss how best to do it.Not just preserve it (it is not a matter of have a file man, please I ask you to not oversimplify this) All the CI is and will rely on such files too!, if not you are forcing people to re-write such information in a dummy file (PIP-s way) please..Either manual with e.g. PIP mode on Odoo and OCA mode on OCB as Moises suggested - but that would be a burden for contributors to understand and maintain both approaches. Or try to generate oca_dependencies.txt and requirements.txt, which should be feasible at first sight, but that's more work. Or keep the status quo :/The easiest way is if you update your workflow instead try to change the current one to something that will left all incomplete....But again on my side I think or both or the current one.
Cheers,-sbiregards!On Sun, Oct 11, 2020 at 7:06 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.-sbi_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 12:11 - 12 Oct 2020 -
Re: 14.0 branches
I think my point is not gotten here.Odoo itself is not pip-intallable (or is it?)On the other hand, 100% of the PIP environment depends on the versioning system (which is human dependable and not related to git at least AFAICK).Everything that depends on the Version instead of the SHA of my will be more complicated.but again.Current more popular software and languages understood the key is in git manae for deployment not in versioning files git enclosure 100% of dependencies on files and information, versioning is not.(see go lang for example)Then going to PIP is going back to the **oldway** not the other way around.If that's makes you happy it is ok, but I think it is wrong.There is only 1 place where is the true "The source code" >> uncle bob.Regards/El dom., 11 de oct. de 2020 a la(s) 13:55, Nhomar Hernández (nhomar@vauxoo.com) escribió:El sáb., 10 de oct. de 2020 a la(s) 00:57, Roussel, Denis (denis.roussel@acsone.eu) escribió: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.I invite you to follow https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/introduction-to-the-oca-code-quality-and-testing-infrastructure-33You'll discover the magic ;-)But who will actually write the **Version**?? to bump theversion you needto duplicate the work that it does by itself....Instead pip install module==versiongit pull --options shaSame command... I mean... You are right, It is a preference topic, just that.See youLe 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. #trunkdevelopmentCheers!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.2. Travis installs dependencies with pip, including addons of other repos1. 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.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 installedIf 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:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}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 themThere 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--
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
--Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomarMéxico · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 11:46 - 11 Oct 2020 -
Re: 14.0 branches
El sáb., 10 de oct. de 2020 a la(s) 00:57, Roussel, Denis (denis.roussel@acsone.eu) escribió: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.I invite you to follow https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/introduction-to-the-oca-code-quality-and-testing-infrastructure-33You'll discover the magic ;-)But who will actually write the **Version**?? to bump theversion you needto duplicate the work that it does by itself....Instead pip install module==versiongit pull --options shaSame command... I mean... You are right, It is a preference topic, just that.See youLe 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. #trunkdevelopmentCheers!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.2. Travis installs dependencies with pip, including addons of other repos1. 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.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 installedIf 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:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}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 themThere 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--
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 08:56 - 11 Oct 2020 -
Re: 14.0 branches
As said, my only goal is to improve the OCA contribution workflow.Of course, I don't want to force any specific installation method onto integrators workflows.So let's try to keep the discussion focused.To be a little bit more specific, here are some aspects that the new method improves:Less RedundancyWhat is in requirements.txt must be added manually and is redundant to addons manifests. oca_dependencies.txt is also redundant and the information can be found elsewhere.
Better testing of dependency declarations
We don't test external python dependencies declarations in manifests because we rely on a redundant, manually maintained requirements.txt
pylint-odoo helps but there are limits to what it can detect.
Also, we publish wheels for OCA addons because it is by far the easiest for newcomers (and veterans alike I should say) to discover dependencies (addons and external python dependencies). Bad dependencies makes for a suboptimal user experience for newcomers installing the wheels.
Reduced blast radius when addons are introduced with specific test requirements, or "exotic" test requirements break
When an addon has specific test requirements it has side effects in all repos that transitively depend on its repo, whether or not the modules are actually needed. When installing dependencies at the addon level instead of the repo level, we drastically reduce the blast radius of such things. Examples: server_environment that required a mandatory option in odoo.cfg. Or an obscure dependency of some rarely used addon in server-tools that suddenly breaks on PyPI and impacts all repos that transitively depend on server-tools because they all end up installing all requirements.txt of server-tools. When that happens, the impact is usually so wide that everyone has to rush to find solutions to unlock the situation. If the impact is contained to the addon and those that depend on it, that buys us more time to find good solutions.Finer grained approach to declaring unmerged dependenciesWith the optional test-requirements.txt, you can declare override dependencies to target unmerged individual addons like this:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}This means you can reference several PRs of the same repos, or several addons of different PRs in another repo (I don't think one can do that with oca_dependencies.txt, where you reference whole repos).[BTW, @Moises, to answer your question above you could use such references to your own repos. And it reduces the need to use git-aggregator too. - but I digress]To close the list, I'd say dependency management is hard and relying on the broader python ecosystem to solve the problem can only help us in the long run (pip in particular is going to release a new sophisticated dependency resolver later this year). And Odoo is not particularly messy nor does it have anything very special in that matter.So how can we progress?For the reasons above, I'd like to move out of the status quo.In the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete.So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback.No harm is done (there are no cross-repo dependencies in v14 branches yet :) and as said, we can easily push an update to .travis.yml.
And the good thing is that the feedback is coming:- At this point I see Moises who says it relies on oca_dependencies.txt in its workflow.- Daniel mentioned a documentation value of oca_dependencies.txt.A few questions:- @Moises, do you rely on requirement.txt too in your own workflow ?- Do others rely on it ? (for instance, does Dooba need oca_dependencies.txt, requirements.txt in OCA repos ?)
If we conclude that oca_dependencies.txt and/or requirements.txt must be preserved in all repos in v14 (and I'm totally fine with that), we can then discuss how best to do it. Either manual with e.g. PIP mode on Odoo and OCA mode on OCB as Moises suggested - but that would be a burden for contributors to understand and maintain both approaches. Or try to generate oca_dependencies.txt and requirements.txt, which should be feasible at first sight, but that's more work. Or keep the status quo :/
Cheers,-sbiOn Sun, Oct 11, 2020 at 7:06 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.-sbi
by Stéphane Bidoul - 07:15 - 11 Oct 2020 -
Re: 14.0 branches
On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.-sbi
by Stéphane Bidoul - 07:11 - 11 Oct 2020 -
Re: 14.0 branches
Maybe we can do something in ocabot that generates an entry in oca dependencies if needed. @Stephane what do you think?Le dim. 11 oct. 2020 à 17:32, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> a écrit :I think the point is not to defend one method of another, although I'm also against pip, as it twists IMO Odoo requirements for adapting to pip. The point is that this unplanned change can impact in a lot of companies that have developed their deployment strategies based on what has been during a lot of years the OCA standard, without time to react and adapt.Regards.El dom., 11 oct. 2020 17:22, Simone Orsi <simahawk@gmail.com> escribió:Hola Nhomar,On Sat, Oct 10, 2020 at 12:21 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).It seems your rationale is not based on a full knowledge of the tool (and probably that's the case for me for oca-deps ;)).Please, read below.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).With pip you pin the single module, not just the repo. It means that you can pin each version or hash atomically per each module. No matter if it comes from OCA or your organization, no matter if it comes from a PR. With oca_dependencies.txt is impossible to have the same preciseness of pinnings AFAIK.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).What does this mean? If you mean "old style deployments where customers download the repo they want and they might edit files randomly" then I think you have another kind of issue ;PIn any case, you can install in edit mode the local repo, eg: `pip install -e path/to/repo/setup/$mod_name`and you'll have the module installed from your local checkout where you can still run `git status`.`pip freeze` will still tell you on which hash it has been installed.The only downside of this is that you should install each module to make it installable in Odoo and fetch non local dependencies automatically.d. Some artifacts on t2d are done to even freeze odoo SHA.I don't get what's the issue here. With pip you would do `pip install -e path/to/odoo` (or github url) and the current hash will be pinned.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.Can you elaborate on this? It's not clear what you mean.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.As explained above, with pip you have much more granularity of pinning modules and versions from wherever you want.2.- With PIP:a.- pip install module.b.- pray for nobody to change something because you will never know what happened.Exactly the contrary: you install a specific version. If you want people to be able to edit things on live instances then you would install them locally w/ `-e` and then you'll still have your beloved `git status`.c.- pray the guy in charge updates the dependencies well.If the module has the wrong dependency you are in trouble anyway. The good part is that you don't care about dependencies anymore unless you want to pin some fork or PR -> all the modules needed for that module will be pulled automatically, python dependencies included. If you installed a fork, pip freeze will produce a good requirements.txt with the right dependencies -> you can reproduce the same env.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.Again, can you elaborate on this?I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!I don't think it is a good idea to keep the world messy just because it started as a mess :)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 think the misunderstandings are everywhere in this thread :)1. oca_dependencies.txt is not gone (to be honest, I asked if it was dead more for the rest of the world than for me, because I followed the process of the pip option introduction started in way back this year)2. pip has way more capabilities than oca_dependencies.txt (as far I can tell), you just have to discover them3. the 2 things can coexist and we can gradually transition to pip IF - and I think Stéphane was very clear on this - we don't have any major issue. To discover if we have issues, we should adopt it a bit more widely and provide docs and training about it -> at the OCA days we'll have some good talks on this.4. As Stéphane mentioned, we could have a way to generate oca_dependencies.txt automatically to leave more freedom for personal/customer deployments.That being said, there are maybe some other powerful features related to oca_deps that we don't see.Probably it would be a good idea to have a comparison table.I hope my point is better explained.Same here :)Abrazos,S.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. #trunkdevelopmentCheers!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.2. Travis installs dependencies with pip, including addons of other repos1. 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.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 installedIf 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:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}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 themThere 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--
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull 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
_______________________________________________
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 - 05:41 - 11 Oct 2020 -
Re: 14.0 branches
Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?Imagine module A and module B in the same repository. Module B depends on A.Changes are made in module A. Will travis run test on module B?2nd case:Imagine module A and module B in the same repository. They don’t depend on each other.New changes are introduced in module A that unintentionally breaks module B.Will travis run tests in module B?I remember the previous setup catching a few issues of this kind.Le dim. 11 oct. 2020 à 12:32, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> a écrit :I think the point is not to defend one method of another, although I'm also against pip, as it twists IMO Odoo requirements for adapting to pip. The point is that this unplanned change can impact in a lot of companies that have developed their deployment strategies based on what has been during a lot of years the OCA standard, without time to react and adapt.Regards.El dom., 11 oct. 2020 17:22, Simone Orsi <simahawk@gmail.com> escribió:Hola Nhomar,On Sat, Oct 10, 2020 at 12:21 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).It seems your rationale is not based on a full knowledge of the tool (and probably that's the case for me for oca-deps ;)).Please, read below.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).With pip you pin the single module, not just the repo. It means that you can pin each version or hash atomically per each module. No matter if it comes from OCA or your organization, no matter if it comes from a PR. With oca_dependencies.txt is impossible to have the same preciseness of pinnings AFAIK.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).What does this mean? If you mean "old style deployments where customers download the repo they want and they might edit files randomly" then I think you have another kind of issue ;PIn any case, you can install in edit mode the local repo, eg: `pip install -e path/to/repo/setup/$mod_name`and you'll have the module installed from your local checkout where you can still run `git status`.`pip freeze` will still tell you on which hash it has been installed.The only downside of this is that you should install each module to make it installable in Odoo and fetch non local dependencies automatically.d. Some artifacts on t2d are done to even freeze odoo SHA.I don't get what's the issue here. With pip you would do `pip install -e path/to/odoo` (or github url) and the current hash will be pinned.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.Can you elaborate on this? It's not clear what you mean.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.As explained above, with pip you have much more granularity of pinning modules and versions from wherever you want.2.- With PIP:a.- pip install module.b.- pray for nobody to change something because you will never know what happened.Exactly the contrary: you install a specific version. If you want people to be able to edit things on live instances then you would install them locally w/ `-e` and then you'll still have your beloved `git status`.c.- pray the guy in charge updates the dependencies well.If the module has the wrong dependency you are in trouble anyway. The good part is that you don't care about dependencies anymore unless you want to pin some fork or PR -> all the modules needed for that module will be pulled automatically, python dependencies included. If you installed a fork, pip freeze will produce a good requirements.txt with the right dependencies -> you can reproduce the same env.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.Again, can you elaborate on this?I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!I don't think it is a good idea to keep the world messy just because it started as a mess :)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 think the misunderstandings are everywhere in this thread :)1. oca_dependencies.txt is not gone (to be honest, I asked if it was dead more for the rest of the world than for me, because I followed the process of the pip option introduction started in way back this year)2. pip has way more capabilities than oca_dependencies.txt (as far I can tell), you just have to discover them3. the 2 things can coexist and we can gradually transition to pip IF - and I think Stéphane was very clear on this - we don't have any major issue. To discover if we have issues, we should adopt it a bit more widely and provide docs and training about it -> at the OCA days we'll have some good talks on this.4. As Stéphane mentioned, we could have a way to generate oca_dependencies.txt automatically to leave more freedom for personal/customer deployments.That being said, there are maybe some other powerful features related to oca_deps that we don't see.Probably it would be a good idea to have a comparison table.I hope my point is better explained.Same here :)Abrazos,S.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. #trunkdevelopmentCheers!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.2. Travis installs dependencies with pip, including addons of other repos1. 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.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 installedIf 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:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}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 themThere 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--_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull 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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Iván Todorovich - 05:41 - 11 Oct 2020 -
Re: 14.0 branches
I think the point is not to defend one method of another, although I'm also against pip, as it twists IMO Odoo requirements for adapting to pip. The point is that this unplanned change can impact in a lot of companies that have developed their deployment strategies based on what has been during a lot of years the OCA standard, without time to react and adapt.Regards.El dom., 11 oct. 2020 17:22, Simone Orsi <simahawk@gmail.com> escribió:Hola Nhomar,On Sat, Oct 10, 2020 at 12:21 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).It seems your rationale is not based on a full knowledge of the tool (and probably that's the case for me for oca-deps ;)).Please, read below.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).With pip you pin the single module, not just the repo. It means that you can pin each version or hash atomically per each module. No matter if it comes from OCA or your organization, no matter if it comes from a PR. With oca_dependencies.txt is impossible to have the same preciseness of pinnings AFAIK.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).What does this mean? If you mean "old style deployments where customers download the repo they want and they might edit files randomly" then I think you have another kind of issue ;PIn any case, you can install in edit mode the local repo, eg: `pip install -e path/to/repo/setup/$mod_name`and you'll have the module installed from your local checkout where you can still run `git status`.`pip freeze` will still tell you on which hash it has been installed.The only downside of this is that you should install each module to make it installable in Odoo and fetch non local dependencies automatically.d. Some artifacts on t2d are done to even freeze odoo SHA.I don't get what's the issue here. With pip you would do `pip install -e path/to/odoo` (or github url) and the current hash will be pinned.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.Can you elaborate on this? It's not clear what you mean.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.As explained above, with pip you have much more granularity of pinning modules and versions from wherever you want.2.- With PIP:a.- pip install module.b.- pray for nobody to change something because you will never know what happened.Exactly the contrary: you install a specific version. If you want people to be able to edit things on live instances then you would install them locally w/ `-e` and then you'll still have your beloved `git status`.c.- pray the guy in charge updates the dependencies well.If the module has the wrong dependency you are in trouble anyway. The good part is that you don't care about dependencies anymore unless you want to pin some fork or PR -> all the modules needed for that module will be pulled automatically, python dependencies included. If you installed a fork, pip freeze will produce a good requirements.txt with the right dependencies -> you can reproduce the same env.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.Again, can you elaborate on this?I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!I don't think it is a good idea to keep the world messy just because it started as a mess :)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 think the misunderstandings are everywhere in this thread :)1. oca_dependencies.txt is not gone (to be honest, I asked if it was dead more for the rest of the world than for me, because I followed the process of the pip option introduction started in way back this year)2. pip has way more capabilities than oca_dependencies.txt (as far I can tell), you just have to discover them3. the 2 things can coexist and we can gradually transition to pip IF - and I think Stéphane was very clear on this - we don't have any major issue. To discover if we have issues, we should adopt it a bit more widely and provide docs and training about it -> at the OCA days we'll have some good talks on this.4. As Stéphane mentioned, we could have a way to generate oca_dependencies.txt automatically to leave more freedom for personal/customer deployments.That being said, there are maybe some other powerful features related to oca_deps that we don't see.Probably it would be a good idea to have a comparison table.I hope my point is better explained.Same here :)Abrazos,S.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. #trunkdevelopmentCheers!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.2. Travis installs dependencies with pip, including addons of other repos1. 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.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 installedIf 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:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}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 themThere 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--
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull 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 Pedro M. Baeza - 05:30 - 11 Oct 2020 -
Re: 14.0 branches
Hola Nhomar,On Sat, Oct 10, 2020 at 12:21 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).It seems your rationale is not based on a full knowledge of the tool (and probably that's the case for me for oca-deps ;)).Please, read below.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).With pip you pin the single module, not just the repo. It means that you can pin each version or hash atomically per each module. No matter if it comes from OCA or your organization, no matter if it comes from a PR. With oca_dependencies.txt is impossible to have the same preciseness of pinnings AFAIK.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).What does this mean? If you mean "old style deployments where customers download the repo they want and they might edit files randomly" then I think you have another kind of issue ;PIn any case, you can install in edit mode the local repo, eg: `pip install -e path/to/repo/setup/$mod_name`and you'll have the module installed from your local checkout where you can still run `git status`.`pip freeze` will still tell you on which hash it has been installed.The only downside of this is that you should install each module to make it installable in Odoo and fetch non local dependencies automatically.d. Some artifacts on t2d are done to even freeze odoo SHA.I don't get what's the issue here. With pip you would do `pip install -e path/to/odoo` (or github url) and the current hash will be pinned.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.Can you elaborate on this? It's not clear what you mean.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.As explained above, with pip you have much more granularity of pinning modules and versions from wherever you want.2.- With PIP:a.- pip install module.b.- pray for nobody to change something because you will never know what happened.Exactly the contrary: you install a specific version. If you want people to be able to edit things on live instances then you would install them locally w/ `-e` and then you'll still have your beloved `git status`.c.- pray the guy in charge updates the dependencies well.If the module has the wrong dependency you are in trouble anyway. The good part is that you don't care about dependencies anymore unless you want to pin some fork or PR -> all the modules needed for that module will be pulled automatically, python dependencies included. If you installed a fork, pip freeze will produce a good requirements.txt with the right dependencies -> you can reproduce the same env.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.Again, can you elaborate on this?I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!I don't think it is a good idea to keep the world messy just because it started as a mess :)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 think the misunderstandings are everywhere in this thread :)1. oca_dependencies.txt is not gone (to be honest, I asked if it was dead more for the rest of the world than for me, because I followed the process of the pip option introduction started in way back this year)2. pip has way more capabilities than oca_dependencies.txt (as far I can tell), you just have to discover them3. the 2 things can coexist and we can gradually transition to pip IF - and I think Stéphane was very clear on this - we don't have any major issue. To discover if we have issues, we should adopt it a bit more widely and provide docs and training about it -> at the OCA days we'll have some good talks on this.4. As Stéphane mentioned, we could have a way to generate oca_dependencies.txt automatically to leave more freedom for personal/customer deployments.That being said, there are maybe some other powerful features related to oca_deps that we don't see.Probably it would be a good idea to have a comparison table.I hope my point is better explained.Same here :)Abrazos,S.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. #trunkdevelopmentCheers!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.2. Travis installs dependencies with pip, including addons of other repos1. 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.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 installedIf 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:odoo14-addon-{addon_name} @ git+https://github.com/OCA/{repo}@refs/pull/{PR}/head#subdirectory=setup/{addon_name}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 themThere 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--_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
by Simone Orsi - 05:21 - 11 Oct 2020
