Contributors mailing list archives
Re: Recommended Contributor Tooling (RCT)by
ok, I understand... Actually, that was why I was a bit wondering seeing you putting emphasis on the big git repos, because I was right to think, that you already solved this in voodoo. Let me think about the custom code... This custom code, I assume in most of the time, external dependency and python dependency prone? Or is there a significant percentage, where we talk about advanced hardware integration and physical bus, despite of the network connection?
I'll think it over...
I'm really commited to the idea of a golang precompiled vodoo, which takes care of the git setup and the docker run commands. This can then possible expanded to cover all existing use cases that python vodoo has... But I think, with those both command, we can create a really genious onborading. And a converge our development environments in the community. This is a good thing, in theory and on the long run... :D
El lun., 19 oct. 2015 a las 16:22, Raphaël Valyi (<email@example.com>) escribió:
David,Voodoo at least download the odoo git repo just once and caches it on the host. As for a build process, today 99% of the Odoo economy is made selling customized projects that involves custom code. That means there is some build process, at least starting from a stable pre-built stack and converging to the exact project code at least this is again the philosophy behind Voodoo.May be one day Odoo and a large set of module is going to be mature enough to be used out of the box in more than 1% of the Odoo economy, but that will not happen that soon. 2016 will be dedicated to run after Odoo 9 in the OCA. Then there will be Odoo 10 and 2016-2017 will run after it too. At least that will evolve until they refactor the MRP and deprecate the old API and then eventually with the Python £ migration... After that may be the product will be mature enough, may be eventually Odoo will not manage to raise enough money to change everything again, may be the economy of the installed user base will finally get bigger than the speculation about the future user base. But we arent't there yet, so yes we have to deal with a moving target and build process...On Mon, Oct 19, 2015 at 6:08 PM, David Arnold <firstname.lastname@example.org> wrote:I think there is a paradigmatic shift in our discussion. Big gits are only a problem, if you download them over and over again from the internet. So just don't! Once is enough. Outside of the build process. What build process anyway? Docker is about not having to repeat such a thing until deep environment changes...Can you agree?Moises,I'll look at what you did, and probably there s some convergence. I see value in being able to spin a Dockerized Runbot in anyway...But about the cache specifically; In Voodoo we wanted to make it work with both Odoo 7, 8 and 9, official Odoo branches, OCB or even custom fork. If we putted all that in the image, that would make the image more than 1Go more to download and then unpack on the disk on our poor SSD disks... (The Voodoo image is already 2Go, making it 3Go would kind of kill the user experience) So instead we let the buildout download a shallow clone of the wanted Odoo repo and we cache it somewhere on the host. I'm open to change that logic but this is how we did until now. And this is more or less the same logic for the Python eggs.Regards.On Mon, Oct 19, 2015 at 3:08 PM, Moises Lopez <email@example.com> wrote:> 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).Yes this is a big problem because the creation of instance is too slow.FYI We fix it with a "cache" into image similar to travis build cache.We have in base image a `git clone odoo` then after create a container MQT execute a `git pull odoo VERSION`Now you don't need download each `docker run` full odoo repo just download last changes from last build image.I will review the Consul process to know other way.Thnk you.2015-10-18 20:07 GMT-05:00 Raphaël Valyi <firstname.lastname@example.org>: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.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...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, DavidOn Sun, Oct 18, 2015 at 2:38 PM, David Arnold <email@example.com> 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.odoo developer bookIf 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.--------