Community mailing list archives
Re: OCA Command Line Interfaceby
I'll share further progress on this on the GitHub repo, rather. If you're interested, I invite you again to join this shared learning experience, you can just star/follow the repo: https://github.com/blaggacao/vodoo/ I'd also love to hear you input, ideas, learnings.
See you there!
Thanks and Best Regards
El vie., 23 oct. 2015 a las 12:12, Dominique Chabord (<email@example.com>) escribió:
Thank you.David,can you just be a bit less noisy on this mailing list and post when you have some information to share ?2015-10-23 18:12 GMT+02:00 David Arnold <firstname.lastname@example.org>:Damn, no luck for windows with devstep, right now: "Please note that the CLI is currently limited to connecting to a local
/var/run/docker.socksocket only and the user that runs
devstepcommands will need non-root access to it. Support for execution over TCP is likely to be added at some point."Raphael, for a quick resolution of possible misunderstandings or open question, you can also ping me on hangouts under this email, in order to not the clutter this thread with individual questions. I'm happy to then feedback the results here again for public record.Ok, Raphael, I think I got it.Desvstep is boilerplate INSIDE the container. So this is cool, as THERE we have a tightly controlled environment. Also it seems pretty lightweight and to contain a lot of best practices out of the ecosystem. Basically one could say:"Devstep is some of docker ecosystems best practices written down in code."I assume it has a "resume" option, and would be happy if you can confirm. So to avoid rebuilding every time. (this still is prone to unexpected behavior because of the layer caching).However, as we are INSIDE the container, things are by definition ephemeral. This is suitable for everything which by character is ephemeral, too. As Moses is proposing with his workflow, this is fine for source code also. However, I do not agree, because usually this includes a remote over the internet (!) git proxy (if it could be made local, this would be an option, indeed).If you propose to prepare your working director(ies) (with receipt) from INSIDE the docker, and persist it on the local disc via the docker volumes api, you pretend managing a whole local host folder structure from WITHIN the docker. This can be done only in a sensible manner, if we adopt some kind of common folder layout, as for example implemented by the golang go get command. Because we wold manage a single root folder and take care of the folder hierarchy and let it be entirely managed by voodoo.This is basically what I'm trying to achieve with a single rewrite of the go build command, re-use their best practices in almost everything (from folder hirarchy to package registry and validation checks) and then hand over to a docker run factory, where devstep definitively is an interesting candidate (for the dev setup). As it is so lightweight, I like the idea. However, it is not a silver bullet, as one might have understood when reading your comments, it is just some bash coded best practices on how to set up a docker from WITHIN.What devstep does not provide is a common definition for OCA base images, that can be mixed and matched and flexibly adapted to the myriad of deploy strategies...I hope this addresses you idea comprehensively, please ask if something remains unclear. I would have preferred to have this discussion on a github PR, as it is easier to organize thoughts there, but I did not receive one, so for this time, I felt forced to use this unhandy mailing list for this purpose. Still, I'm happy to receive a proposal PR to deepen the integration details on the host-docker and on the docker-runtime interfaces...Best Regards, DavidRaphael, on question, for the build command, is there a better documentation about devstep as the wow, yeahy and yay index page?Furthering my analysis, here is a nicely build Package Struct:
https://github.com/golang/go/blob/release-branch.go1.5/src/cmd/go/pkg.go#L28-L102My idea is to rewrite the build sub-command as to construct odoo modules into this package struct. The rest of the get command execution code rarely touches go specifics and should behave well with some little commenting out. There is a single gateway implemented here (https://github.com/golang/go/blob/master/src/cmd/go/pkg.go#L346)It would be nice, if anyone could point me to the lines, where anybox receipt handles it's dependency registry for odoo dependencies, to see what can be refactored. I honestly didn't find something.One way, I find very useful to get started for a python people is to use: https://github.com/mailgun/godebug After installing and breakpointing your files and compiling, you'll find the debug-compiled executable in your working tree. Quite handy.Nhomar, although you're presenting your concerns in a way that is bending common limits of respect, I'm happy to receive your technical feedback on the GitHub repository, if you decide to contribute.2015-10-22 13:22 GMT-05:00 David Arnold <email@example.com>:Nhmoar, please!I didn't ask anyone's opinion about it. I asked for dynamic volunteers to take part in this adventure and make this odoo place a better place. If you want to contribute, please stick to the (very short!) contributing guidline.One time you put such crazyness here you are asking my opinion by default.If you do not want opinions, then:Create your own mailing list.Your own chat systemMake marketing.Bring some ass kissers to you.IF:You want thinking people giving opinion don't:Spoil other projects (that's absolutly wrong).Try to change things you clearly do not understand.Use incorrect channels to spread "ideas".ANDAccept hard critics, and work on support your points.That's not what OpenSource threat about.BUT IF:You want support and respect show a little of respect in the practice not in words (talk respectfully but sending wrong messages IS disrepectful and clearly condecendente in a negative way).Show respect "trying" at least what is done..... if you demonstrate you learn use it, then you demonstrate at least you give the correct respect.FROM MY POV:This thread is a clear spoil to the project and objectives of a lot of things, it is not a matter of technology, it is just a matter of way of work.Sorry.!--