thanks @RemiBardon maybe you can share with them the docker recipe we use, e.g.: swift-docker/Dockerfile at main · apple/swift-docker · GitHub
it basically does 3 steps:
apt-get install
I shared them the link, I'll tell you if it helps with the problem.
@tomerd Your Dockerfile says maintainers are swift-infrastructure@swift.org, my colleagues will contact this email directly to avoid polluting this topic.
But TL;DR, they'd like a tarball with all the dependencies' tarballs already inside, not a script which downloads them because the script doesn't have network access at build time.
Hey all, as someone who has started and never finished a few server side Swift projects (both Vapor and Kitura), I'll like to share my thoughts on server side Swift visibility. It is not my intention to throw cold water on the efforts for the working group, or the developers that build frameworks such as Vapor. This is just one man's opinion of the state of Swift on the server and its ability to gain a foot hold in the market.
There are a few core audiences that would utilize these frameworks: mobile developers who need an API, "modern" web app developers who are using React/Angular front ends, and developers who focus on building more traditional web apps where the server is compiling and returning HTML. I'm sure there are other use cases, but this is what I primarily deal with so I'll stick to them.
To me the current server side Swift frameworks work best for individuals building APIs to connect to mobile applications. Developers in the Apple ecosystem can easily pick up the skills necessary build APIs and necessary infrastructure to power their apps. The tutorials and examples on the web favor this use case.
The reality is that even mobile application developers need web apps, so the ability to launch web apps with server side Swift is paramount.
"Modern" web applications built using client side JavaScript libraries such as React and Angular drastically increase the complexity of developing web applications. The client side libraries require a complex build system (babel, webpack, etc) to be setup in conjunction with the server side language of choice. Not only is the development environment more complex, but deploying to the application to the cloud becomes more complex as now the client side JS needs to be complied and deployed along with the server side Swift. For novice developers this becomes an obstacle. The complexity of the environment and deployment becomes and obstacle do building/playing around with a framework. Most tutorials on the internet will focus building React/Vue/Angular apps with node back ends, so naturally new developers gravitate towards that ecosystem. From a server side Swift perspective, it would be helpful for newbies if there was more information on how structure, develop and deploy such apps as a whole. In its current state, server side swift seems like it would be a good fit for these types of applications, but it has to contend with a large body of tutorials and documentation that focuses on other languages.
For more traditional web applications where HTML is compiled and sent to the browser for rendering the current server side Swift frameworks feel incomplete. While there are templating languages such as Leaf that make it easy to build dynamic pages, there is a fair amount of infrastructure missing. For example: how do I compile/minify ES6; how do I incorporate external JavaScript libraries; how do I integrate SASS; how do I render object validation errors within a response from the server? Experienced developers may be able to piece together a solution for these issues, but the novice developers will find the experience frustrating and leave for a different framework.
My recommendation would be to focus onboarding new developers to server side Swift. Focus on making it easier for developers to build "Modern" and traditional web applications through improving integration within the development environments, building the tooling they need to make onboarding easier, and making a major push in the publishing of tutorials.
Epilogue:
I can remember when Ruby on Rails was just released. One of the first tutorials was build a blog in 15 minutes. Before Rails a fair amount of time was needed to setup a development environment. The configuration of a Java spring application wasn't exactly a trivial task. Building a ColdFusion app still required the developer to setup databases, learn connection strings, and write SQL. Rails changed all that. The power of seeing an application with models, views, validation, etc build in 15 minutes was industry changing.
Fast forward to today. Our development environments are more complex than they ever have been. The industry ripe for a technology to simplify the process. If you want market penetration, focus on helping developers get to market easier and faster.