Official Docker Image & "Blessing"s of Community Platforms

Fastmail · December 29, 2015, 6:07pm

Hi all,

You might want to settle down with a glass of eggnog to read this, it's a long one.

Myself and Haris Amin (CC'd), as you may know, have been building a community of users who want to use Swift inside Docker containers (https://github.com/swiftdocker/docker-swift\) and maintain an image, swiftdocker/swift, that provides a complete Swift installation that is usable for all kinds of applications, from trying a Linux REPL to running a webserver (I've already deployed one).

We've been contacted by a content evangelist at Docker who would like to offer an "official" Docker image that contains Swift. You can read more about official Docker images here: https://docs.docker.com/docker-hub/official_repos/\. Note that these are official in Docker Inc.'s view: they don't necessarily exist as officially supported by, for instance, PyPy developers, but they are a great starting point and exhibit best practices. Docker is interested in having Haris and I maintain the image we have been building as the official repository. There's a lot of benefits to having an official Docker image, namely enhanced security, scrutiny, support, and a spotlight on a great new language that can drive adoption.

Haris and I are incredibly thankful for the hard work Swift's core team have put into the open sourcing of the language and in that spirit we are very reluctant to proceed without the core team's blessing. The important thing to note is that this endeavour would involve little to no work on the core team's side, except perhaps a note on the Downloads page saying that this is a community supported project and not one officially supported by the core team.

This brings to a head something that's been rumbling for a while: how exactly does the Swift Project "bless" alternative distributions or platforms? For instance, the recent work on compiling to ARM for the Raspberry Pi is a worthy project, notably for the Pi's adoption in educational environments. BSD systems are another area of great interest. Furthermore, I doubt it will be long before someone wants to provide a Swift package through apt-get, homebrew etc. While those contributors may have less qualms about wanting the Swift team's blessing, it makes sense that there is some degree of centrality to ensure people do not work independently towards the same goal for a particular platform.

For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.

For the larger matter, it seems to me that the Swift Project can take a few directions:
1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.

I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.

Best wishes for the new year,

Thomas Catterall

···

Sent from my iPhone

Jeremy_Fergason · December 29, 2015, 10:12pm

I think this is a timely discussion. I’ve been working on putting together packages for Fedora and RHEL/CentOS 6/7. The RHEL series tends to be quite slow on updating packages so building is a bit tricky. It would be nice if users at swift.org had just a quick reference to where the packages could be pulled from if desired.

I’ll post to this list when the rpm’s are available for general use.

Happy New Year!

Jeremy Fergason

···

On Dec 29, 2016, at 11:07 AM, Thomas Catterall via swift-dev <swift-dev@swift.org> wrote:

Hi all,

You might want to settle down with a glass of eggnog to read this, it's a long one.

Myself and Haris Amin (CC'd), as you may know, have been building a community of users who want to use Swift inside Docker containers (GitHub - apple/swift-docker: Docker Official Image packaging for Swift
) and maintain an image, swiftdocker/swift, that provides a complete Swift installation that is usable for all kinds of applications, from trying a Linux REPL to running a webserver (I've already deployed one).

We've been contacted by a content evangelist at Docker who would like to offer an "official" Docker image that contains Swift. You can read more about official Docker images here: Docker Official Images | Docker Docs
. Note that these are official in Docker Inc.'s view: they don't necessarily exist as officially supported by, for instance, PyPy developers, but they are a great starting point and exhibit best practices. Docker is interested in having Haris and I maintain the image we have been building as the official repository. There's a lot of benefits to having an official Docker image, namely enhanced security, scrutiny, support, and a spotlight on a great new language that can drive adoption.

Haris and I are incredibly thankful for the hard work Swift's core team have put into the open sourcing of the language and in that spirit we are very reluctant to proceed without the core team's blessing. The important thing to note is that this endeavour would involve little to no work on the core team's side, except perhaps a note on the Downloads page saying that this is a community supported project and not one officially supported by the core team.

This brings to a head something that's been rumbling for a while: how exactly does the Swift Project "bless" alternative distributions or platforms? For instance, the recent work on compiling to ARM for the Raspberry Pi is a worthy project, notably for the Pi's adoption in educational environments. BSD systems are another area of great interest. Furthermore, I doubt it will be long before someone wants to provide a Swift package through apt-get, homebrew etc. While those contributors may have less qualms about wanting the Swift team's blessing, it makes sense that there is some degree of centrality to ensure people do not work independently towards the same goal for a particular platform.

For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.

For the larger matter, it seems to me that the Swift Project can take a few directions:
1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.

I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.

Best wishes for the new year,

Thomas Catterall

Sent from my iPhone
<embedded image>_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

ddunbar · January 4, 2016, 5:24pm

Hi Thomas,

Just a question: how would the constant changing of the Swift compiler version and language interact with this? It seems odd to have an "official" version of what is an otherwise unreleased language version/compiler.

- Daniel

···

On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swift-dev <swift-dev@swift.org> wrote:

Hi all,

You might want to settle down with a glass of eggnog to read this, it's a long one.

Myself and Haris Amin (CC'd), as you may know, have been building a community of users who want to use Swift inside Docker containers (https://github.com/swiftdocker/docker-swift\) and maintain an image, swiftdocker/swift, that provides a complete Swift installation that is usable for all kinds of applications, from trying a Linux REPL to running a webserver (I've already deployed one).

We've been contacted by a content evangelist at Docker who would like to offer an "official" Docker image that contains Swift. You can read more about official Docker images here: https://docs.docker.com/docker-hub/official_repos/\. Note that these are official in Docker Inc.'s view: they don't necessarily exist as officially supported by, for instance, PyPy developers, but they are a great starting point and exhibit best practices. Docker is interested in having Haris and I maintain the image we have been building as the official repository. There's a lot of benefits to having an official Docker image, namely enhanced security, scrutiny, support, and a spotlight on a great new language that can drive adoption.

Haris and I are incredibly thankful for the hard work Swift's core team have put into the open sourcing of the language and in that spirit we are very reluctant to proceed without the core team's blessing. The important thing to note is that this endeavour would involve little to no work on the core team's side, except perhaps a note on the Downloads page saying that this is a community supported project and not one officially supported by the core team.

This brings to a head something that's been rumbling for a while: how exactly does the Swift Project "bless" alternative distributions or platforms? For instance, the recent work on compiling to ARM for the Raspberry Pi is a worthy project, notably for the Pi's adoption in educational environments. BSD systems are another area of great interest. Furthermore, I doubt it will be long before someone wants to provide a Swift package through apt-get, homebrew etc. While those contributors may have less qualms about wanting the Swift team's blessing, it makes sense that there is some degree of centrality to ensure people do not work independently towards the same goal for a particular platform.

For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.

For the larger matter, it seems to me that the Swift Project can take a few directions:
1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.

I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.

Best wishes for the new year,

Thomas Catterall

Sent from my iPhone

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

tkremenek · January 11, 2016, 10:53pm

Hi Thomas and Harris,

First, my apologies for the slow response. Docker + Swift is a great combination that I'd be very interested in exploring as having a more official support from the Swift.org project.

This is something I need to discuss more with the rest of Swift Core, but what I'm looking for is #3 or #4. From my perspective, having official support for Docker would be about adding a new sibling download next to the Swift binary downloads for Xcode and Linux (Ubuntu). It's something I think we'd be open for exploring as long as their were active maintainers of the Docker image and a clear way for the Docker images to be built in an automated way.

For reference, right now the snapshots we provide for downloads (both Xcode and Linux) are produced by a continuous integration system we have at Apple. For context, that continuous integration system should soon be available out in the open. Ideally, Docker images would also be produced by the same continuous integration system as well, and aligns with what you said for #4. It would also be important to have a way to make sure the produced Docker packages were functional.

If we took #4, I would imagine there are a couple of code owners for maintaining the Docker image. They would be responsibility for curating content going into the image itself. I would also expect them to help define the functionality of that image, and help crafting a story so that it can be maintained in an automated way.

More generally, there's an interesting discussion about increasing the variants of binary packages on Swift.org. For example, before the open source launch we discussed whether or not to publish rpms, debs, etc. for Linux and settled on tar files because of their simplicity and that we hoped that, if the community interest was there, others besides the Swift team at Apple could play a role in helping provide curated packages for specific distributions. How exactly this would work logistically will likely have different answers for different platforms. For some it may make sense to distribute those on Swift.org, and for others to distribute them independently, possibly with a nod from the Swift.org website (option #2 and #3).

Ted

···

On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swift-dev <swift-dev@swift.org> wrote:

For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.

For the larger matter, it seems to me that the Swift Project can take a few directions:
1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.

I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.

Fastmail · January 4, 2016, 6:17pm

Hi Daniel,

We'd release new images as new snapshots are released; we don't do it yet but we can "tag" images so that you could pin your image to a particular snapshot.

Tom

···

Sent from my iPhone

On 4 Jan 2016, at 12:24, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

Hi Thomas,

Just a question: how would the constant changing of the Swift compiler version and language interact with this? It seems odd to have an "official" version of what is an otherwise unreleased language version/compiler.

- Daniel

On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swift-dev <swift-dev@swift.org> wrote:

Hi all,

You might want to settle down with a glass of eggnog to read this, it's a long one.

Myself and Haris Amin (CC'd), as you may know, have been building a community of users who want to use Swift inside Docker containers (https://github.com/swiftdocker/docker-swift\) and maintain an image, swiftdocker/swift, that provides a complete Swift installation that is usable for all kinds of applications, from trying a Linux REPL to running a webserver (I've already deployed one).

We've been contacted by a content evangelist at Docker who would like to offer an "official" Docker image that contains Swift. You can read more about official Docker images here: https://docs.docker.com/docker-hub/official_repos/\. Note that these are official in Docker Inc.'s view: they don't necessarily exist as officially supported by, for instance, PyPy developers, but they are a great starting point and exhibit best practices. Docker is interested in having Haris and I maintain the image we have been building as the official repository. There's a lot of benefits to having an official Docker image, namely enhanced security, scrutiny, support, and a spotlight on a great new language that can drive adoption.

Haris and I are incredibly thankful for the hard work Swift's core team have put into the open sourcing of the language and in that spirit we are very reluctant to proceed without the core team's blessing. The important thing to note is that this endeavour would involve little to no work on the core team's side, except perhaps a note on the Downloads page saying that this is a community supported project and not one officially supported by the core team.

This brings to a head something that's been rumbling for a while: how exactly does the Swift Project "bless" alternative distributions or platforms? For instance, the recent work on compiling to ARM for the Raspberry Pi is a worthy project, notably for the Pi's adoption in educational environments. BSD systems are another area of great interest. Furthermore, I doubt it will be long before someone wants to provide a Swift package through apt-get, homebrew etc. While those contributors may have less qualms about wanting the Swift team's blessing, it makes sense that there is some degree of centrality to ensure people do not work independently towards the same goal for a particular platform.

For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.

For the larger matter, it seems to me that the Swift Project can take a few directions:
1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.

I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.

Best wishes for the new year,

Thomas Catterall

Sent from my iPhone

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Fastmail · January 18, 2016, 8:36am

Hi Ted, all,

Picking this up after a few days, Haris and I have both had unusually busy weeks (job interviews on my part).

What I can conclude from this is that there's no active "no" here, and given that an official docker image is better than none, Haris and I will go ahead and work with Docker to start maintaining an official image. You know where to find us!

When Apple open up their CI to the world, I would love to be involved in helping set up docker infrastructure for that, and distributing snapshots as part of it.

Onwards to a containerised future!

As for the more general issue about blessing distributions, I'm glad we've had some discussion about this - I'm sure it's generated some internally as well, and for now that's all I need to know. The ad hoc basis upon which other distributions are proceeding is quite suited to the low volume for now, and no formal process is necessary. I'm very glad Ted approves of more involvement between the Swift project and third party maintainers, and I hope this view is shared by many more.

All the best, and I hope you're still having a great new year,

Tom

···

Sent from my iPhone

On 11 Jan 2016, at 22:53, Ted kremenek <kremenek@apple.com> wrote:

On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swift-dev <swift-dev@swift.org> wrote:

For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.

For the larger matter, it seems to me that the Swift Project can take a few directions:
1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.

I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.

Hi Thomas and Harris,

First, my apologies for the slow response. Docker + Swift is a great combination that I'd be very interested in exploring as having a more official support from the Swift.org project.

This is something I need to discuss more with the rest of Swift Core, but what I'm looking for is #3 or #4. From my perspective, having official support for Docker would be about adding a new sibling download next to the Swift binary downloads for Xcode and Linux (Ubuntu). It's something I think we'd be open for exploring as long as their were active maintainers of the Docker image and a clear way for the Docker images to be built in an automated way.

For reference, right now the snapshots we provide for downloads (both Xcode and Linux) are produced by a continuous integration system we have at Apple. For context, that continuous integration system should soon be available out in the open. Ideally, Docker images would also be produced by the same continuous integration system as well, and aligns with what you said for #4. It would also be important to have a way to make sure the produced Docker packages were functional.

If we took #4, I would imagine there are a couple of code owners for maintaining the Docker image. They would be responsibility for curating content going into the image itself. I would also expect them to help define the functionality of that image, and help crafting a story so that it can be maintained in an automated way.

More generally, there's an interesting discussion about increasing the variants of binary packages on Swift.org. For example, before the open source launch we discussed whether or not to publish rpms, debs, etc. for Linux and settled on tar files because of their simplicity and that we hoped that, if the community interest was there, others besides the Swift team at Apple could play a role in helping provide curated packages for specific distributions. How exactly this would work logistically will likely have different answers for different platforms. For some it may make sense to distribute those on Swift.org, and for others to distribute them independently, possibly with a nod from the Swift.org website (option #2 and #3).

Ted

haris · January 4, 2016, 6:45pm

Yes we can most definitely tag images for snapshots. Maybe our versioning could reflect that too.

Haris

···

On January 4, 2016 at 1:17:56 PM, Thomas Catterall (me@swizzlr.co) wrote:

Hi Daniel,

We'd release new images as new snapshots are released; we don't do it yet but we can "tag" images so that you could pin your image to a particular snapshot.

Tom

Sent from my iPhone

On 4 Jan 2016, at 12:24, Daniel Dunbar <daniel_dunbar@apple.com> wrote:

Hi Thomas,

Just a question: how would the constant changing of the Swift compiler version and language interact with this? It seems odd to have an "official" version of what is an otherwise unreleased language version/compiler.

- Daniel

On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swift-dev <swift-dev@swift.org> wrote: