Hi Tom, > With docker compose, the following commands: > >> docker build -t swift-dev-image . >> docker create -it --name development -v >> /my/absolute/path/to/swift:/container/mount-point swift-dev-image >> docker start -ai development > > Become: > >> docker-compose up
Fair enough (for some reason I’ve never thought of using compose for a single container, but it totally makes sense). Let’s see what you’ll come up with! 👍 max > On Dec 18, 2015, at 7:06 PM, Thomas Catterall <m...@swizzlr.co> wrote: > > Hi Max, > > Thanks for your reply and encouragement! I will do just that. > > 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. > > 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: > >> docker build -t swift-dev-image . >> docker create -it --name development -v >> /my/absolute/path/to/swift:/container/mount-point swift-dev-image >> docker start -ai development > > Become: > >> docker-compose up > > > 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. > > 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. > > 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. > > I would be very, very interested in hearing from Swift developers about ways > of accelerating time to development by providing build intermediates. > > Best, > > Tom > > Sent from my iPhone > > On 18 Dec 2015, at 21:25, Max Moiseev <mois...@apple.com > <mailto:mois...@apple.com>> wrote: > >> 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. >> >> 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’? >> >> 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. >> >> thanks, >> max >> >>> On Dec 18, 2015, at 12:34 PM, swizzlr via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> Hacking on Swift >>> >>> 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. >>> >>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
