Message Threads | The Odoo Community Association

Re: 14.0 branches

@Nhomar Hernandez it was just a simplified example, skipping a few steps. We use doodba these days, so for general purposes dev/test/production are the same. But using doodba, in general you do any non client specific development in a seperate generalised build. Otherwise you end up in another special type of git hell.

by Graeme Gellatly - 01:56 - 13 Oct 2020

Re: 14.0 branches

El lun., 12 de oct. de 2020 a la(s) 15:32, Graeme Gellatly (gdgellatly@gmail.com) escribió:

Hi,

Honestly I tried both ways. Trying to have nice neat build OCA installing modules. I even setup own Pypi server to distribute client modules. This is basically how the pip workflow worked.

pip install some_module
Oh it has a bug and I need to make a PR.
pip uninstall some_oca_module
git clone OCA/Web
git-aggregator file while PR waiting.

pip install some_other_module
rinse repeat.

I can't honestly see the fix on OCA/web in which environment was done, on production? or in a second environment?

Felt like every single module. Now maybe in a pure deployment environment pip works, maybe once a release is mature it does too and maybe I am a dinosaur and my workflow using git is stupid, but I just don't like using the python packaging for Odoo. Just too much stuff from too many different places. And unless every module you want to use is pip available then it just feels like 2 different processes even when there are no issues.

On Tue, Oct 13, 2020 at 9:12 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:
Hello Daniel.

Yes I understand.

AFAIK there is a problem with the version in pip.

How do you cohexsists 14-13-12-11 in the same environment?
How do you manage to do "from odoo import odoo" and falling apart virtualenv, how do you manage such coexistence?

I am pretty sure it is out of the scope from odoo (but they are not closed to do it) because the owner of the pip package is vauxoo.

https://pypi.org/project/odoo/

Olivier asked us a few years ago to give it to them but then after a few conversations it was never a priority to them (but maybe that will change).

Regards.

PS: can you share the command to tray it from github?

I tried several options and I can't get it to work.

El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (dreis@opensourceintegrators.com) escribió:
On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

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

--
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

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

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 12:31 - 13 Oct 2020

Re: 14.0 branches

BTW:

In my previous email, Share/Maintain and contribute cost us almost 0. (we expend 10 hours designing/discussing/programming vs 10 minutos sharing this).

El lun., 12 de oct. de 2020 a la(s) 17:24, Nhomar Hernández (nhomar@vauxoo.com) escribió:

Let me show graphically.

How do you audit a server?

dev-test-ci-production environments are as much alike as possible [1].

Then when debugging and development the flow to consume is:

Consume.
$ git pull repository.

Share and propose.
$ git checkout -b branch
$ git push
$ git PR.

With 5 commands 100% of the:

Test.
Update.
Staging.
Production

Are 100% the same (even the CHECKSUM OF FILES ARE THE SAME).

That mindset rely on git (impossible or at least more complicated with PIP).

An example of this working:

With 1 click I update all/audit and analize (in the image is our own vauxoo.com instance) we have more information without give access to our production server, but I hope it explains itself.

I hope it helps.

Good practice says: CI-DEV-TEST-PROD should be as equal as possible. (spotify is one of the best examples for this) https://github.com/spotify/luigi.

Distribution of the package I am 100% agree with PIP (that's not my point) my point is rely on PIP for the CI and come back to oca_dependencies.txt when this must be in the other way around, oca_dependencies.txt gererates the PIP package.

And force has only 1 way to do it.

Regards.

El lun., 12 de oct. de 2020 a la(s) 15:32, Graeme Gellatly (gdgellatly@gmail.com) escribió:
Hi,

Honestly I tried both ways. Trying to have nice neat build OCA installing modules. I even setup own Pypi server to distribute client modules. This is basically how the pip workflow worked.

pip install some_module
Oh it has a bug and I need to make a PR.
pip uninstall some_oca_module
git clone OCA/Web
git-aggregator file while PR waiting.

pip install some_other_module
rinse repeat.

Felt like every single module. Now maybe in a pure deployment environment pip works, maybe once a release is mature it does too and maybe I am a dinosaur and my workflow using git is stupid, but I just don't like using the python packaging for Odoo. Just too much stuff from too many different places. And unless every module you want to use is pip available then it just feels like 2 different processes even when there are no issues.

On Tue, Oct 13, 2020 at 9:12 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:
Hello Daniel.

Yes I understand.

AFAIK there is a problem with the version in  pip.

How do you cohexsists 14-13-12-11 in the same environment?
How do you manage to do "from odoo import odoo" and falling apart virtualenv, how do you manage such coexistence?

I am pretty sure it is out of the scope from odoo (but they are not closed to do it) because the owner of the pip package is vauxoo.

https://pypi.org/project/odoo/

Olivier asked us a few years ago to give it to them but then after a few conversations it was never a priority to them (but maybe that will change).

Regards.

PS: can you share the command to tray it from github?

I tried several options and I can't get it to work.

El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (dreis@opensourceintegrators.com) escribió:
On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

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

--
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com  vauxoo.com/contactus

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

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

--
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com  vauxoo.com/contactus

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 12:31 - 13 Oct 2020

1 attachments 1 attachments

Re: 14.0 branches

Let me show graphically.

How do you audit a server?

dev-test-ci-production environments are as much alike as possible [1].

Then when debugging and development the flow to consume is:

Consume.

$ git pull repository.

Share and propose.

$ git checkout -b branch

$ git push

$ git PR.

With 5 commands 100% of the:

Test.

Update.

Staging.

Production

Are 100% the same (even the CHECKSUM OF FILES ARE THE SAME).

That mindset rely on git (impossible or at least more complicated with PIP).

An example of this working:

With 1 click I update all/audit and analize (in the image is our own vauxoo.com instance) we have more information without give access to our production server, but I hope it explains itself.

I hope it helps.

Good practice says: CI-DEV-TEST-PROD should be as equal as possible. (spotify is one of the best examples for this) https://github.com/spotify/luigi.

Distribution of the package I am 100% agree with PIP (that's not my point) my point is rely on PIP for the CI and come back to oca_dependencies.txt when this must be in the other way around, oca_dependencies.txt gererates the PIP package.

And force has only 1 way to do it.

Regards.

El lun., 12 de oct. de 2020 a la(s) 15:32, Graeme Gellatly (gdgellatly@gmail.com) escribió:

Hi,

Honestly I tried both ways. Trying to have nice neat build OCA installing modules. I even setup own Pypi server to distribute client modules. This is basically how the pip workflow worked.

pip install some_module
Oh it has a bug and I need to make a PR.
pip uninstall some_oca_module
git clone OCA/Web
git-aggregator file while PR waiting.

pip install some_other_module
rinse repeat.

Felt like every single module. Now maybe in a pure deployment environment pip works, maybe once a release is mature it does too and maybe I am a dinosaur and my workflow using git is stupid, but I just don't like using the python packaging for Odoo. Just too much stuff from too many different places. And unless every module you want to use is pip available then it just feels like 2 different processes even when there are no issues.

On Tue, Oct 13, 2020 at 9:12 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:
Hello Daniel.

Yes I understand.

AFAIK there is a problem with the version in pip.

How do you cohexsists 14-13-12-11 in the same environment?
How do you manage to do "from odoo import odoo" and falling apart virtualenv, how do you manage such coexistence?

I am pretty sure it is out of the scope from odoo (but they are not closed to do it) because the owner of the pip package is vauxoo.

https://pypi.org/project/odoo/

Olivier asked us a few years ago to give it to them but then after a few conversations it was never a priority to them (but maybe that will change).

Regards.

PS: can you share the command to tray it from github?

I tried several options and I can't get it to work.

El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (dreis@opensourceintegrators.com) escribió:
On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

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

--
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

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

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 12:25 - 13 Oct 2020

1 attachments 1 attachments

Re: 14.0 branches

Certainly not opinionated very much on this,
i remember the "outdated library issue" in many many 
Java Enterprise Applications installations out there and 
i have the feeling that this is significantly easier 
to run into if you use a merely PIP approach on Odoo deployments as
well but i might be wrong on this one. On the other hand there may be 
advantages for auditability of ERP systems if you use PIP

Best Frederik

Am Montag, den 12.10.2020, 20:31 +0000 schrieb Graeme Gellatly:

> Hi,

> 

> Honestly I tried both ways. Trying to have nice neat build OCA

> installing modules. I even setup own Pypi server to distribute client

> modules. This is basically how the pip workflow worked.

> 

> pip install some_module

> Oh it has a bug and I need to make a PR.

> pip uninstall some_oca_module

> git clone OCA/Web

> git-aggregator file while PR waiting.

> 

> pip install some_other_module

> rinse repeat.

> 

> Felt like every single module. Now maybe in a pure deployment

> environment pip works, maybe once a release is mature it does too and

> maybe I am a dinosaur and my workflow using git is stupid, but I just

> don't like using the python packaging for Odoo. Just too much stuff

> from too many different places. And unless every module you want to

> use is pip available then it just feels like 2 different processes

> even when there are no issues.

> 

> On Tue, Oct 13, 2020 at 9:12 AM Nhomar Hernández <nhomar@vauxoo.com>

> wrote:

> > Hello Daniel.

> > 

> > Yes I understand.

> > 

> > AFAIK there is a problem with the version in  pip.

> > 

> > How do you cohexsists 14-13-12-11 in the same environment?

> > How do you manage to do "from odoo import odoo" and falling

> > apart virtualenv, how do you manage such coexistence?

> > 

> > I am pretty sure it is out of the scope from odoo (but they are not

> > closed to do it) because the owner of the pip package is vauxoo.

> > 

> > https://pypi.org/project/odoo/

> > 

> > Olivier asked us a few years ago to give it to them but then after

> > a few conversations it was never a priority to them (but maybe that

> > will change).

> > 

> > Regards.

> > 

> > PS: can you share the command to tray it from github?

> > 

> > I tried several options and I can't get it to work.

> > 

> > El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (

> > dreis@opensourceintegrators.com) escribió:

> > > On 12/10/2020 11:07, Nhomar Hernández wrote:

> > > > Do you think Odoo will be pip-installable in some moment?

> > > > 

> > >  

> > > Just clearing this one, yes it is, thanks to some key

> > > contribution Stéphane made into the Odoo core.

> > > 

> > > Actually, I'll have a talk at the OCA Days called "pip install

> > > odoo":

> > > https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

> > > 

> > > I personally find it very convenient and use it everyday in my

> > > dev environments.

> > > (Don't ask me about using it in deployment, my infrastructure

> > > team doesn't let me put a finger in their servers...).

> > > 

> > > Thanks

> > > Daniel

> > > 

> > > _______________________________________________

> > > Mailing-List: https://odoo-community.org/groups/contributors-15

> > > Post to: mailto:contributors@odoo-community.org

> > > Unsubscribe: https://odoo-community.org/groups?unsubscribe

> > 

> > 

-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

by Frederik Kramer - 11:20 - 12 Oct 2020

Re: 14.0 branches

> BTW (trolling mode on) that title is a click bait:

I can't see the picture, but reading this thread taught me quite a bit about 
pip, that's a good thing, thanks :-)

As a buildout and doodba user, I don't see the problem. All of the above are 
some of the preferred ways of distributing our work, and Stephane chose what's 
most convenient for him. The way tests are set up or how test dependencies are 
pulled won't affect any deployment, so I really don't see why we would make a 
fuzz about that? Especially as you have to opt in for that on repo level as he 
explained.

And doing away with some oca specifics like oca_dependenciens.txt also is good 
for any deployment strategy, right?

I'm pro Stephane's work

Best,
Holger


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com

by Holger Brunn - 11:05 - 12 Oct 2020

1 attachments 1 attachments

Re: 14.0 branches

Hi,

Honestly I tried both ways. Trying to have nice neat build OCA installing modules. I even setup own Pypi server to distribute client modules. This is basically how the pip workflow worked.

pip install some_module

Oh it has a bug and I need to make a PR.

pip uninstall some_oca_module

git clone OCA/Web

git-aggregator file while PR waiting.

pip install some_other_module

rinse repeat.

Felt like every single module. Now maybe in a pure deployment environment pip works, maybe once a release is mature it does too and maybe I am a dinosaur and my workflow using git is stupid, but I just don't like using the python packaging for Odoo. Just too much stuff from too many different places. And unless every module you want to use is pip available then it just feels like 2 different processes even when there are no issues.

On Tue, Oct 13, 2020 at 9:12 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:

Hello Daniel.

Yes I understand.

AFAIK there is a problem with the version in pip.

How do you cohexsists 14-13-12-11 in the same environment?
How do you manage to do "from odoo import odoo" and falling apart virtualenv, how do you manage such coexistence?

I am pretty sure it is out of the scope from odoo (but they are not closed to do it) because the owner of the pip package is vauxoo.

https://pypi.org/project/odoo/

Olivier asked us a few years ago to give it to them but then after a few conversations it was never a priority to them (but maybe that will change).

Regards.

PS: can you share the command to tray it from github?

I tried several options and I can't get it to work.

El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (dreis@opensourceintegrators.com) escribió:
On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

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

--
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

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

by Graeme Gellatly - 10:30 - 12 Oct 2020

Re: 14.0 branches

BTW (trolling mode on) that title is a click bait:

El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (dreis@opensourceintegrators.com) escribió:

On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 10:16 - 12 Oct 2020

1 attachments 1 attachments

Re: 14.0 branches

Hello Daniel.

Yes I understand.

AFAIK there is a problem with the version in pip.

How do you cohexsists 14-13-12-11 in the same environment?

How do you manage to do "from odoo import odoo" and falling apart virtualenv, how do you manage such coexistence?

I am pretty sure it is out of the scope from odoo (but they are not closed to do it) because the owner of the pip package is vauxoo.

https://pypi.org/project/odoo/

Olivier asked us a few years ago to give it to them but then after a few conversations it was never a priority to them (but maybe that will change).

Regards.

PS: can you share the command to tray it from github?

I tried several options and I can't get it to work.

El lun., 12 de oct. de 2020 a la(s) 12:47, Daniel Reis (dreis@opensourceintegrators.com) escribió:

On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 10:11 - 12 Oct 2020

Re: Is there a way to create account.analytic.line from stock.move?

Reading all the code I got all confused - you're right it's there in stock_account.

Initially I wanted to report that the code you provided does not seem to work for me - the stock move inside stock picking associated with Sale Order does not receive analytical account information. But I found the culprit later on. The part of code that I initially thought is alredy present in procurement_mto_analytic is this:

def _prepare_procurement_values(self, group_id=False):

        res = super()._prepare_procurement_values(group_id)

        res.update({"account_analytic_id": self.order_id.analytic_account_id.id})

        return res

However what you posted was this:

res.update({"analytic_account_id": self.order_id.analytic_account_id.id})

In stock_analytic (in fact in sale) the field is named analytic_account_id but in procurement_mto_analytic it's account_analytic_id. I missed this detail initially and of course it didn't work. Throughout the codebase of stock Odoo both names are used for some reason. The same goes for account-analytic OCA repository.

Best regards

Radovan

On pondelok 12. októbra 2020 17:02:34 CEST Dominique k wrote:

> look at the module stock_account

> Regards, Dominique

> On Mon, 12 Oct 2020 at 20:05, Radovan Skolnik < radovan@skolnik.info [1] >

> wrote: Oh, now I see (after long staring at various pieces of code).

> Account Move (account.move) ensures creation of Analytic Entries

> (account.analytic.line) for Account Move Lines (account.move.line) that are

> validated. So that way OCA module stock_analytic provides the possibility

> to create Analytic Entries in _prepare_account_move_line method...

>

> OK, now I'll update the code of procurement_mto_analytic (actually only the

> second part as the first part is there already - or should that be another

> module or even a new one?) with the code you provided, the analytical

> account value should be propagated into stock move lines. Now does stock

> move somehow relate to account move (to generate analytic entries)? Does

> not seem to me so...

>

> Thank you very much for info. Best regards

>

> Radovan

>

> On pondelok 12. októbra 2020 12:26:51 CEST Dominique k wrote:

> > in odoo standard, analytic entries (account.analytic.line) are generated

> > with journal entries (== invoices in v13 onwards). It is also possible to

> > create analytic entries separately, typically with timesheet. In fact

> > timesheet entries are analytic lines with the OCA module stock_analytic,

> > analytic entries are created when a stock move is validated. that is all

> > as

> > far as i know. other modules, do not generate analytic lines, instead,

> > they

> > add an analytic account to a document, which eventually ends up/link up

> > as/with a timesheet, an invoice or a stock move. Regards, Dominique

> > _______________________________________________

> > Mailing-List: https://odoo-community.org/groups/contributors-15 [2] [1]

> > Post to: mailto: contributors@odoo-community.org [3]

> > Unsubscribe: https://odoo-community.org/groups?unsubscribe [4] [2]

> >

> > [1] https://odoo-community.org/groups/contributors-15 [5]

> > [2] https://odoo-community.org/groups?unsubscribe [6]

>

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [7]

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [8]

>

> [1] mailto:radovan@skolnik.info

> [2] https://odoo-community.org/groups/contributors-15

> [3] mailto:contributors@odoo-community.org

> [4] https://odoo-community.org/groups?unsubscribe

> [5] https://odoo-community.org/groups/contributors-15

> [6] https://odoo-community.org/groups?unsubscribe

> [7] https://odoo-community.org/groups/contributors-15

> [8] https://odoo-community.org/groups?unsubscribe

by Radovan Skolnik - 09:21 - 12 Oct 2020

Re: 14.0 branches

On 12/10/2020 11:07, Nhomar Hernández wrote:

Do you think Odoo will be pip-installable in some moment?

Just clearing this one, yes it is, thanks to some key contribution Stéphane made into the Odoo core.

Actually, I'll have a talk at the OCA Days called "pip install odoo":
https://odoo-community.org/event/oca-days-2020-online-training-and-learning-event-2020-10-15-2020-10-16-121/track/pip-install-odoo-61

I personally find it very convenient and use it everyday in my dev environments.
(Don't ask me about using it in deployment, my infrastructure team doesn't let me put a finger in their servers...).

Thanks
Daniel

by Daniel Reis - 07:46 - 12 Oct 2020

Re: 14.0 branches

El lun., 12 de oct. de 2020 a la(s) 07:52, Alexandre Fayolle (alexandre.fayolle@camptocamp.com) escribió:

I'm happy with generated requirements.txt and oca_dependencies files. This will remove some errors caused by manual management of these files anyway.

Regarding oca_dependencies: I use them to easily find when an addon is defined, where to direct a contribution, etc. I also happened to "discover" some OCA repositories that way.

+1

Regarding requirements.txt: the latest version of Odoo's runbot uses these to install the requirements. It will help using OCA repositories on Odoo.sh, and I think it is a valuable service we provide to our users.

+1

Regarding pip installation of addons, I'm not sure this is available on odoo.sh, and I think this is a use case we should not underestimate.

odoo.sh will not work with pip, this is one of the more important parts, it depends strongly of git.

And the user itself have currently 1 place to read in odoo.sh where is the extra code (very important), information that was tested perfectly (and not auto-generated).

Super valid man + 1

Le lun. 12 oct. 2020 à 09:07, Mignon, Laurent <laurent.mignon@acsone.eu> a écrit :
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.

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 Redundancy

What 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.txt

With 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 dependencies

With 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,

-sbi

regards!

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: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

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

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

--
Alexandre Fayolle
Chef de Projet
Tel : + 33 (0)4 58 48 20 30

Camptocamp France SAS
http://www.camptocamp.com

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 07:06 - 12 Oct 2020

Re: 14.0 branches

El lun., 12 de oct. de 2020 a la(s) 05:22, Pedro M. Baeza (Tecnativa) (pedro.baeza@tecnativa.com) escribió:

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).

+1

Regards.

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 07:00 - 12 Oct 2020

Re: 14.0 branches

El lun., 12 de oct. de 2020 a la(s) 10:42, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:

On Mon, Oct 12, 2020 at 12:07 PM Nhomar Hernández <nhomar@vauxoo.com> wrote:


> 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.

Sorry Nhomar, I stopped reading what you wrote at this (very
offensive) sentence.

No means to offend, just to explain how I feel! I openly ask for apologizes if you feel offended but I yet feel like I express and keep that position.

I just ask you to understand my position a little bit, this was not open to discussion long enough and not executed in the right way (even if at the end you are right).

-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: @nhomar

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 07:00 - 12 Oct 2020

Re: 14.0 branches

El lun., 12 de oct. de 2020 a la(s) 05:22, Roussel, Denis (denis.roussel@acsone.eu) escribió:

Hi Nhomar,

SHA management with git is fully supported: pip install <addon-name> <git-url>@<sha>#subdirectory=<setup dir>

No man, it is not, it is not installg from git, in all case it would be:

** git clone repo.

** python setup install path/to/local/folder.

** pray!

I mean the installation is not in the same folder than the code.

Now is just black magic:

** git clone path/to/addons/

** Automatically read the oca_dependencies (no human interaction).

** Run odoo: no human interaction either.

All is git controlled.

BTW just for the records: I know I can do pip install repository, but that's not what I am talking about here, but the control of the deployed instance itsef frm an oca_dependencies file and with git-controlled environment.

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.txt

I 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!

Regards

I 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 Redundancy

What 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.txt

With 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 dependencies

With 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,

-sbi

regards!

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: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com  vauxoo.com/contactus

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

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

--
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com  vauxoo.com/contactus

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

--
__________________________________________
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 57

Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | Belgium
Quai Banning, 6 (Val Benoît) | B-4000 Liège | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
www.acsone.eu

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

--

Nhomar G Hernández

Vauxoo | CEO

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

México · Venezuela · Costa Rica · Perú

phone nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 06:56 - 12 Oct 2020

Re: 14.0 branches

On Mon, Oct 12, 2020 at 12:07 PM Nhomar Hernández <nhomar@vauxoo.com> wrote:

> 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.

Sorry Nhomar, I stopped reading what you wrote at this (very
offensive) sentence.

-sbi

by Stéphane Bidoul - 05:40 - 12 Oct 2020

Re: 14.0 branches

Thank you Alexandre these are valid technical points.

I'll see if I can find an easy way to generate oca_dependencies.txt
and requirements.txt. If not I'll revert to the previous way.

On Mon, Oct 12, 2020 at 2:51 PM Alexandre Fayolle
<alexandre.fayolle@camptocamp.com> wrote:

>

> I'm happy with generated requirements.txt and oca_dependencies files. This will remove some errors caused by manual management of these files anyway.

>

> Regarding oca_dependencies: I use them to easily find when an addon is defined, where to direct a contribution, etc. I also happened to "discover" some OCA repositories that way.

>

> Regarding requirements.txt: the latest version of Odoo's runbot uses these to install the requirements. It will help using OCA repositories on Odoo.sh, and I think it is a valuable service we provide to our users.

>

> Regarding pip installation of addons, I'm not sure this is available on odoo.sh, and I think this is a use case we should not underestimate.

by Stéphane Bidoul - 05:36 - 12 Oct 2020

Re: Is there a way to create account.analytic.line from stock.move?

look at the module stock_account

Regards,

Dominique

On Mon, 12 Oct 2020 at 20:05, Radovan Skolnik <radovan@skolnik.info> wrote:

Oh, now I see (after long staring at various pieces of code). Account Move
(account.move) ensures creation of Analytic Entries (account.analytic.line)
for Account Move Lines (account.move.line) that are validated. So that way OCA
module stock_analytic provides the possibility to create Analytic Entries in
_prepare_account_move_line method...

OK, now I'll update the code of procurement_mto_analytic (actually only the
second part as the first part is there already - or should that be another
module or even a new one?) with the code you provided, the analytical account
value should be propagated into stock move lines. Now does stock move somehow
relate to account move (to generate analytic entries)? Does not seem to me
so...

Thank you very much for info. Best regards

Radovan

On pondelok 12. októbra 2020 12:26:51 CEST Dominique k wrote:
> in odoo standard, analytic entries (account.analytic.line) are generated
> with journal entries (== invoices in v13 onwards). It is also possible to
> create analytic entries separately, typically with timesheet. In fact
> timesheet entries are analytic lines with the OCA module stock_analytic,
> analytic entries are created when a stock move is validated. that is all as
> far as i know. other modules, do not generate analytic lines, instead, they
> add an analytic account to a document, which eventually ends up/link up
> as/with a timesheet, an invoice or a stock move. Regards, Dominique
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [1]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [2]
>
>
>
> [1] https://odoo-community.org/groups/contributors-15
> [2] https://odoo-community.org/groups?unsubscribe

by dominique.k - 05:01 - 12 Oct 2020

Re: 14.0 branches

I'm happy with generated requirements.txt and oca_dependencies files. This will remove some errors caused by manual management of these files anyway.

Regarding oca_dependencies: I use them to easily find when an addon is defined, where to direct a contribution, etc. I also happened to "discover" some OCA repositories that way.

Regarding requirements.txt: the latest version of Odoo's runbot uses these to install the requirements. It will help using OCA repositories on Odoo.sh, and I think it is a valuable service we provide to our users.

Regarding pip installation of addons, I'm not sure this is available on odoo.sh, and I think this is a use case we should not underestimate.

Le lun. 12 oct. 2020 à 09:07, Mignon, Laurent <laurent.mignon@acsone.eu> a écrit :

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.

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 Redundancy

What 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.txt

With 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 dependencies

With 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,

-sbi

regards!

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: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

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

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

--

Alexandre Fayolle
Chef de Projet
Tel : + 33 (0)4 58 48 20 30

Camptocamp France SAS
http://www.camptocamp.com

by Alexandre Fayolle - 02:50 - 12 Oct 2020

Re: Is there a way to create account.analytic.line from stock.move?

Oh, now I see (after long staring at various pieces of code). Account Move 
(account.move) ensures creation of Analytic Entries (account.analytic.line) 
for Account Move Lines (account.move.line) that are validated. So that way OCA 
module stock_analytic provides the possibility to create Analytic Entries in 
_prepare_account_move_line method...

OK, now I'll update the code of procurement_mto_analytic (actually only the 
second part as the first part is there already - or should that be another 
module or even a new one?) with the code you provided, the analytical account 
value should be propagated into stock move lines. Now does stock move somehow 
relate to account move (to generate analytic entries)? Does not seem to me 
so...

Thank you very much for info. Best regards

	Radovan

On pondelok 12. októbra 2020 12:26:51 CEST Dominique k wrote:

> in odoo standard, analytic entries (account.analytic.line) are generated

> with journal entries (== invoices in v13 onwards). It is also possible to

> create analytic entries separately, typically with timesheet. In fact

> timesheet entries are analytic lines with the OCA module stock_analytic,

> analytic entries are created when a stock move is validated. that is all as

> far as i know. other modules, do not generate analytic lines, instead, they

> add an analytic account to a document, which eventually ends up/link up

> as/with a timesheet, an invoice or a stock move. Regards, Dominique

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 [1]

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [2]

> 

> 

> 

> [1] https://odoo-community.org/groups/contributors-15

> [2] https://odoo-community.org/groups?unsubscribe

by Radovan Skolnik - 02:05 - 12 Oct 2020

Archives

Contributors

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: Is there a way to create account.analytic.line from stock.move?

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: 14.0 branches

Re: Is there a way to create account.analytic.line from stock.move?

Re: 14.0 branches

Re: Is there a way to create account.analytic.line from stock.move?

Follow us