Reducing friction for development (prebuilt VSCode images)

Related Projects
, ,
1

Hello,

An often cited problem for using Swift on other platforms is the effort required to get everything working together. To help address this barrier to entry, I have been exploring some options to reduce the initial friction for development on other targets (e.g. android, Linux, etc).

Now, I realize that some of my choices may be controversial for some, so, I would like to preface this as I am NOT advocating that this be the only development, merely an option for those that would like to use it. I personally prefer to develop locally and use my editor of choice, so I can completely understand why some may be frustrated with some of the tradeoffs made here. Please note that I am not trying to remove those options, merely provide an alternative which others can explore if it suits them.

I have been exploring the idea of creating a pre-configured docker image using Ubuntu 18.04 which is prepackaged with a complete toolchain for C/C++/Swift - clang, clang-format, lld, lldb, etc. It also has a copy of VSCode installed (as a build of coder.com's CodeServer). This means that what you have is a headless server instance that has all the necessary pieces in place - VSCode, toolchain, tools and pre-configured. There are a few volumes which would be "well-known" that are expected to be supplied by the user - locations for the source code and binary artifact. This allows having the ability to have a self-contained toolchain without having to worry about the user's setup. Because everything is self-contained, upgrades/tests are simply a matter of swapping out the container and due to the pre-configured nature of it, do not require adjusting much.

I have been playing around a bit with this, and this largely amounts to a workflow of the following:

  • docker run -v /SourceCache:/SourceCache -v /BinaryCache:/BinaryCache compnerd/swift
  • launch chrome
  • navigate to http://localhost:8080.
    I've been able to build projects in the docker image, and it would be possible to pre-configure a number of additional cross-compilation targets as well simplifying the build setup for e.g. android.

This is something which can easily expand in scope and I do not think that I have enough time to grow this to something more finessed, however, the configuration for this is something which I have on GitHub, and welcome PRs to improve it. I also have some prebuilt images on DockerHub.

The current items which are missing which I would like to see added to this image is llbuild, s-p-m, and SourceKit-LSP. I would like to have SourceKit-LSP also pre-configured so that it is possible to have semantic completion enabled by default.

I welcome PRs to help improve this experience. Hopefully this will reduce the barrier to entry and make it easier for others to get started with developing with Swift.

Happy Thanksgiving!
Saleem

31 Likes
2

I think you already got it right with the installer

I personally think, installer + SPM and a plugin for VSCode (wich already exists -kinda-) are only just needed, anything else will be extra sugar, that's what GO/Rust does already, and looks like it is working for them

why SPM?

because the project can be shared on github and people can get started with a simple: git clone and swift run, no matter what their OS is (as long as the project supports the platform)

and they can get started easily by creating a project, and add packages from github, just like in GO, simple

To be honest, what you describe is a bit scary, maybe a bit too complex?

I kinda repeat myself a little but, but i think SPM is what will truly enable cross-platform adoption of swift, maybe i only speak for myself and completely don't understand what is really needed

Or maybe i misunderstood the goal of this post, my apologies if that's the case

I would like to help a little bit, but need to know if people share the same opinions about SPM

i am completly clueless about android

3

Also side question:

Is it possible to get a definitive list of where the help is exactly needed etc? maybe in a separate thread, so people who randomly jump in can directly see where and how they can help

4

I think that s-p-m is something to work towards, but is not really ready yet. Until cross-compilation is as well supported through it as it is with clang + CMake, I think that alternatives will be necessary. As an example, swift-driver was impossible to support for Windows until Yams had a CMake based build system added since s-p-m cannot cross-compile, and there is more work that is needed in making the code base be completely functional on Windows.

Long term, yes, I can see the usefulness of s-p-m, but, in order to get to that point we need to reduce the barrier to entry for developers. That is what my approach is trying to accomplish.

As to areas of help with this work, I think that further default configuration of the VSCode environment is needed. Adjustments to the toolchain definitions for cross-compilation to android, Im looking at how to best map in the Android NDK (due to concerns around redistribution of licensed content) and the Windows SDK. Setup of SourceKit-LSP, integration of the prebuilt lldb image, setup for debugging, integration of the REPL are some ideas off the top of my head. Of course the previously mentioned thing about llbuild and s-p-m integration still remain on the list too.

5

Back a year ago or so when I was last playing around with Windows, I used SPM to cross-compile from WSL (Ubuntu) to native Windows x64 using a toolchain file like this and it worked well. What's regressed since then?

6

If you want to make a task to be done easily try to make it easy first. One main thing I can do on a project is to work with it and reduce it's fiction whenever performing any task related to it.

Developer Fiction is defined as anything that gives a reason to be hesitant and perform various tasks and work. It depends on multiple things. They are:-

  1. It is a time-consuming task.
  2. It is hard to perform the task efficiently.
  3. It is not hard but it is not usually performed.

Apart from this, it's particular that some things can be performed to reduce the developer friction and is embedded to choose the mentioned items so as to found that reducing developer friction in these areas has become easy.

Things that can be performed:-

  1. Scripted and headless
  2. Reducing Fear
  3. Scriptable interfaces.