<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Tom,</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">With docker compose, the following commands:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">docker build -t swift-dev-image .</div><div class="">docker create -it --name development -v /my/absolute/path/to/swift:/container/mount-point swift-dev-image</div><div class="">docker start -ai development</div></blockquote><div class=""><br class=""></div><div class="">Become:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">docker-compose up</blockquote></div></div></blockquote><br class="">Fair enough (for some reason I’ve never thought of using compose for a single container, but it totally makes sense).</div><div class="">Let’s see what you’ll come up with! 👍</div><div class=""><br class=""></div><div class="">max</div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 7:06 PM, Thomas Catterall <<a href="mailto:me@swizzlr.co" class="">me@swizzlr.co</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Hi Max,</div><div class=""><br class=""></div><div class="">Thanks for your reply and encouragement! I will do just that.</div><div class=""><br class=""></div><div class="">Docker volumes allow you to specify volumes to mount inside the container; where this shines is mounting host directories into the container, so that one can edit files on the host and see the changes reflected immediately in the container.</div><div class=""><br class=""></div><div class="">Docker-compose does a lot of things, but in particular its benefit is that it can encapsulate a lot of configuration for a container. One example of that configuration is the above volumes feature, which is normally a pain to write out on the command line. Another is the usual dance of building an image, creating the container, and then starting and stopping it with the correct state. With docker compose, the following commands:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">docker build -t swift-dev-image .</div><div class="">docker create -it --name development -v /my/absolute/path/to/swift:/container/mount-point swift-dev-image</div><div class="">docker start -ai development</div></blockquote><div class=""><br class=""></div><div class="">Become:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">docker-compose up</blockquote></div><div class=""><br class=""></div><div class="">In my research I have however discovered that this kind of mounting is quite flaky/nonexistent for certain docker hosts, in particular OS X, however there are indeed plugins for docker that use rsync to achieve the desired effect, so it's still quite doable. I'll look into it.</div><div class=""><br class=""></div><div class="">Regarding alternate systems, yes, that would be amazing! Docker base images are rarely reflective of general Linux distributions, so caution is needed when trying to apply them as a way of checking compatibility, but certain fundamental things are possible such as checking Ubuntu 14 vs 15, centOS, Debian, Fedora at a core level. It would be interesting, however, to create functional test suites using full distro base images (I'm sure they exist) that can then have the packages installed on them as a way of verifying a wide array of configurations in an automated fashion.</div><div class=""><br class=""></div><div class="">I think for now my objective will be to provide a quickstart docker image and docker-compose, using a metarepo with submodules to achieve the desired effects.</div><div class=""><br class=""></div><div class="">I would be very, very interested in hearing from Swift developers about ways of accelerating time to development by providing build intermediates.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Tom</div><div class=""><br class=""><div class="">Sent from my iPhone</div></div><div class=""><br class="">On 18 Dec 2015, at 21:25, Max Moiseev <<a href="mailto:moiseev@apple.com" class="">moiseev@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">I personally think it would be of great help to newcomers to have a containerized development environment to quickly start experimenting. Non-newcomers would also benefit from it by being able to test their changes on different versions of Linux, for example.</div><div class=""><br class=""></div><div class="">I would prepare a set of scripts and Dockerfile’s in a separate repo to start with, and at least add a link to it to Swift’s main ‘README’ via a PR to see what the community has to say. Maybe an extra paragraph in 'system requirements’?</div><div class=""><br class=""></div><div class="">On a slightly more technical note, can you elaborate a bit more on why you’d need a docker-compose? If only for volumes to be in a separate container… Maybe I’m missing something.</div><div class=""><br class=""></div><div class="">thanks,</div><div class="">max</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 12:34 PM, swizzlr via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><span class="" style="font-size: 14px;"><b class="">Hacking on Swift</b></span></div></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-size: 14px;"><b class=""><br class=""></b></span></div><div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Just as it’s possible to build Swift in a docker container so too is it possible to actively develop the language in a Linux environment, while still benefitting from any local affordances you may have. If there is interest from the core team, I would be happy to contribute a meta-repo of Swift, submoduleing all the repos and supplying a docker-compose file which would enable developers to provision a development machine while being able to mirror local changes over to the machine. Similarly, “preheated” images could be built which would eliminate the need for a fresh build when first starting on the project.</div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>