1. Mailing Lists
  2. Contributors
  3. Re: Recommended Contributor Tooling (RCT)

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Recommended Contributor Tooling (RCT)

Re: Recommended Contributor Tooling (RCT)

Avatar

Re: Recommended Contributor Tooling (RCT)

by
dar@devco.co
- 19/10/2015 02:52:40
Dear Raphael, Dear Moses

I want to especially invite you two, but also everyone else, to converge our effort on this design document: https://docs.google.com/document/d/11D4gAk05uE7LM5xftaiJexZN1Xbnh3iCcAi8rL7sA_8/edit?usp=sharing

I feel I have identified the perfect place for both tools t2d and voodoo, It would be corresponding to my part to transfer the docker contribution instructions to the OCA world and to figure out together with you the optimal base image. 

Eric, and everyone else working on docker base images, please share your exerience in the document, as well!

I will comment and moderate the file and make sure, that the vision and goals are not los of sight.

I'm really looking forward to your input!

I'm confident, while closely monitoring the docker ecosysten, that, with their latest developments, it is possible ,that we can get something very complete and elegant running in two months time.

Best, David

El dom., 18 oct. 2015 a las 20:26, David Arnold (<dar@devco.co>) escribió:
at the moment it has been lost during the Bash to Python rewrite of the Launcher, but Voodoo run also had some port shifting intelligence when you launch several project at the same time. We would like to have it back...

Basically of course the user could type all the Docker run options and run the akretion/voodoo image manually. But well the Voodoo Python launcher is here to let user just type just "voodoo run" with no risk of error and frustration. So on windows that could eventually be "vagrant up" until Docker compose get mature on Windows which will also probably happen soon given Microsoft investments on Docker.

Ok, I understand the port shifting is indeed something more intelligent, which we cannot have with standard tooling. What would you thing of rewriting this part of voodoo in go and just compile it? This could be the perfect fit for this tooling? This would be even genious, because it could also take care of setting up the git hup repo correctly with upstream and origin tracking branches and probably implementing git-flow for the convenience of the user. This would be really WOW! :D It would standardize the way, we at OCA would use github elegantly. NICE NICE NICE!

El dom., 18 oct. 2015 a las 20:23, Raphaël Valyi (<rvalyi@akretion.com>) escribió:
also David,

at the moment it has been lost during the Bash to Python rewrite of the Launcher, but Voodoo run also had some port shifting intelligence when you launch several project at the same time. We would like to have it back...

Basically of course the user could type all the Docker run options and run the akretion/voodoo image manually. But well the Voodoo Python launcher is here to let user just type just "voodoo run" with no risk of error and frustration. So on windows that could eventually be "vagrant up" until Docker compose get mature on Windows which will also probably happen soon given Microsoft investments on Docker.

Regards.

On Sun, Oct 18, 2015 at 10:57 PM, Raphaël Valyi <rvalyi@akretion.com> wrote:
David,

basicallly what sucks in Odoo is the the repo is huge. So a large part of the Voodoo Python launcher is made to create the options of the docker run command, specially which folder you'll mount to share your Odoo repo (Odoo is too much of a buggy moving target to be bundled inside the image and it's to heavy to be downloaded always).

Alternatively I thought about putting the Voodoo inteligence inside the portable Linux image and like running it twice: one to first output the run options and then eval the command of the second run. That's e technique used by Consul https://github.com/gliderlabs/docker-consul/tree/legacy#runner-command but again sadly that wouldn't work on Windows.

Voodoo also have a few other useful commands. We often use "voodoo new project_name" to bootstrap a new project and hack on something.

Overall, I think the Voodoo Python launcher is useful. But what I think is we can have 80% of the useful features in just 20 lines of Ruby in a Vagrantfile. Then "voodoo run" would be just "Vagrant up" on windows and sharing a project would just work (not the advanced Docker compose feature but f*ck Windows right...)

So again, pull request for a such a Vagrantfile would be greatly appreciated in Voodoo.

Regards.

On Sun, Oct 18, 2015 at 10:38 PM, David Arnold <dar@devco.co> wrote:
Hi Raphael, I'm right now analyzing in detail the docker onboarding guide, that's just a bliss. I'll rewrite it for OCA. THE thing is: We can probably completely drop docker-compose and just work with the priviledged flag, to run multiple containers within the first. thise moves tooling environment definition out of the user machine and into a second layer easily managable via a DOCKERFILE... I'll keep you posted, if that might work...

El dom., 18 oct. 2015 a las 15:07, David Arnold (<dar@devco.co>) escribió:
Thank you nhomar for your opinion.

It is indeed a valuable point, but it is not breaking, because:
a) Easier is always better then complicated.
b) I'm willing to take on the challenge. So I hope, once testable the scope might be reconsidered upon the final thing.

In the end, we have multiple error layers when someone want's to get started on hacking openobject framework, among them are:
virtualisation, autoreloading, debugging, editor, templating, prototyping, python environment, os environment (external dependencies). Some of them take weeks to understand and solve, and for some, there is such a flood of possibilities that chances are high you just give up on the way. This means valuable brainpower lost. (It doesn't serve us someone finding out how to setup his stack, it only serves us someone contributing openobject code, so let's get them there in no time! And this marginal contribution can possibly be the so hardly needed reviewing activity...)

I think this is why broadening the scope, once we have a viable solution is worthwhile..

Guys, share me some enthusiasm! :) That could be more fun for everyone...

Best, David

El dom., 18 oct. 2015 a las 14:52, Nhomar Hernandez (<nhomar@vauxoo.com>) escribió:

On Sun, Oct 18, 2015 at 2:38 PM, David Arnold <dar@devco.co> wrote:
Sorry, you just don't want to burden this onto someone who just want's to get started. Even to us it might be an obvious error. It's not the user's fault, that this is not working. It is the programmer's (as almost always) ...

I insist... you are trying to solve an issue far away from the objective of odoo's project.

If somebody want install odoo and is new and do not understand that error, need to google 2 or 3 minutes and will find the solution.

Even it is better if you recommend 2 or three reads before start.

i.e: learningpythonthehardway.com
     odoo developer book

If you buy i.e Mac or Windows apps.... the next next buttons will make you some questions which th documentation explains conceptually what they are, but if the user do not have tha minimal knowledg you can not expect the system will solve a connection to their brains to teach alá matrix!

Regards.

--
Nhomar Hernandez
CEO Vauxoo.
Twitter: @nhomar
Odoo Gold Partner
Móvil Venezuela:
+58 4144110269
Móvil México:
+52 1 4773933942

_______________________________________________

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

--



--
Raphaël Valyi
Founder and consultant
+55 21 3942-2434


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

Reference