I am a software engineer who has worked for the last three years. I am on a career break and considering applying for GSOC 2025 with Swift. I am a beginner to open-source and getting familiar with the vscode-swift codebase.
I'm interested in working on Swiftly Integration in VS Code.
I have experience working with TypeScript in a professional setting and Swift, mainly as a hobby for developing iOS applications.
I have reviewed the project description and set up a local development environment for vscode-swift and learning more about the code base and working on a pull request to familiarize myself with the process.
I’m aware of Swift in XCode, but this issue is about Swift Extension for VS Code, in which you can use Swift to program for iOS/macOS agnostic programs such as cli tools and servers
Great to see your interest int the project, if you have any specific questions you about the project -- remember that this phase of GSoC is all about preparing a good proposal writeup, including a timeline proposal for the work etc -- please don't hesitate to ask here.
While I was doing some research, I had a few questions:
We require macOS prebuilds to facilitate the automatic installation of Swiftly by the extension. However, as of today, I can only see builds for Linux under Github releases. Do we need to establish some CI infrastructure for MacOS?
Currently, Swiftly outputs data as strings, but to effectively display version information in VS Code, we should modify it to provide structured JSON output.
I’m reviewing other VS Code extensions that provide toolchain switching functionality, like vscode-python and vscode-go. For example, we can make some UX changes by displaying the current Swift version in the VS Code status bar.
Thank you for the interest in this project and these are great questions! I'll try my best to answer them here, but I really like the direction you're going with this so far.
We require macOS prebuilds to facilitate the automatic installation of Swiftly by the extension. However, as of today, I can only see builds for Linux under Github releases. Do we need to establish some CI infrastructure for MacOS?
I'll let @cmcgee1024 answer this in more detail, but I believe there was some design work that needed to be done for Swiftly on macOS to avoid conflicting with Xcode installations.
Currently, Swiftly outputs data as strings, but to effectively display version information in VS Code, we should modify it to provide structured JSON output.
Fully agree with this. Swiftly needs to provide some machine readable output here and JSON is easy to parse in JavaScript land already. Can be enabled with a new flag called --format=json or something along those lines. Would be good to see how other tools such as SwiftPM allow changing the output format just so we're using similar command line options.
I’m reviewing other VS Code extensions that provide toolchain switching functionality, like vscode-python and vscode-go. For example, we can make some UX changes by displaying the current Swift version in the VS Code status bar.
I absolutely love this idea. Being able to see exactly which Swift version you have running and having a quick way to change it is a fantastic user experience. I'll only add that status bar real estate can be a precious resource when you have many extensions installed. So, we may want to limit this to only show when editing a Swift file. Something to think about to make sure we're not going to be trampling over other extensions, anyway.
We require macOS prebuilds to facilitate the automatic installation of Swiftly by the extension. However, as of today, I can only see builds for Linux under Github releases. Do we need to establish some CI infrastructure for MacOS?
Note that swiftly is currently undergoing some major changes in preparation for a 1.0 release. This new release has the macOS support. It also has the functions that will be needed for this project, such as listing the available toolchains.
Until the release is finalized you can build your own release-like packages at desk by first installing a 6.x swift toolchain, cloning the swiftly code at either main or release/1.0 branches, and then running the following command:
swift run build-swiftly-release --skip 0.9.9
Running this on macOS will produce the macOS package, on Linux x86_64, it will be for that OS and architecture, etc.
When the release is finalized, you won't find the packages in the releases tab of GitHub. Instead, it will be offered from swift.org.
Would be good to see how other tools such as SwiftPM allow changing the output format just so we're using similar command line options.
SwiftPM controls output formats for subcommands like swift package show-dependencies wth a --format option:
OVERVIEW: Print the resolved dependency graph
USAGE: swift package show-dependencies [--format <format>] [--output-path <output-path>]
OPTIONS:
--format <format> text | dot | json | flatlist (default: text)
I would expect that it'd be installed globally. Or really, it should just invoke the Swiftly install script and forward any prompts from that to the user. Would need some changes to Swiftly in order to forward the prompts (e.g. something like GIT_ASKPASS that's used by the git extension).
I agree with @matthewbastien that installing it into the user's account would probably be best.
In terms of doing headless installs of swiftly there is some documentation on the topic. Here's guide for installing swiftly in an automated/CI system that might work for this context.
I think that refreshing any existing VSCode shells to get the environment variables, and managing the post-installation steps on Linux will be interesting. There is an option for a post-install file that could be used after the installation to show the user what they need to "apt-get" or "yum" install on their system.
