Or else you can send your mailId, I will add it to the editor list.
Hi everyone! 
I’m Archi, a final-year Honours Computer Science student at the University of Alberta, focused on ML and software development. I’m super passionate about Apple and Swift, I’ve even built an app using Swift.
I’m also new to open-source contributions but really eager to learn and contribute meaningfully. Transitioning from academia to industry I would like to try and explore various different projects such as this one. I’m very interested in the Swiftly Integration project as well, and would love to work alongside others who are exploring it.
Looking forward to collaborating and learning with you all!
~ Archi 
1 Like
Hi @cmcgee1024
Did you get a chance to add feedback to my draft proposal?
Hi @roulpriya ,
Thanks for your patience. I've reviewed your GSoC proposal and overall it looks great.
Here's my feedback regarding the content and some design elements:
Activate toolchain
suggestion: Use the swiftly terminology here. Swiftly "uses" a toolchain version to make it the one that is selected when you run toolchain commands.
We will implement a rendering layer with text and JSON formatters by creating interfaces with implementations for each output format. We will use a command-line argument like --format=json to control the output format
praise: This will make it consistent with SwiftPM, which is great to have within a language ecosystem.
"success": true,
"error": null
question: Why encode these things into each message payload? The exit code of the swiftly process will be zero if it succeeded. If it's non-zero then any error/warning messages should come out of standard error, so VSCode can extract the lines from there. This is rather unlike HTTP where there's only a single response stream. So, the response messages can be made much simpler, especially for init.
Init Toolchain
The init subcommand for swiftly is for installing swiftly itself. One of the side-effects is that it will install the latest swift toolchain, but that's something that can be opted-out with the --skip-install flag. I expect that the VSCode extension might want to opt out, and then explicitly install afterwards with the install sub-command, since there are more options that are available on that sub-command that will help with VSCode integration, such as the post-install file (more on that further down), and a progress file for getting events to update VSCode tasks in the task view.
thought: The init subcommand sometimes emits follow-up shell commands. I expect that the easiest option is for VSCode to restart any terminals so that they can get the new environment variables and changes to the PATH right away, so there would be no need to put these into this JSON output.
List Toolchains
suggestion: When listing the toolchains with the list subcommand, it shows only the installed toolchains, so I don't think that there is a need for an "installed" field for each one.
Install Toolchain
thought: I'm not sure if there's really much need to restate the version of the toolchain that was requested, whether it's default, in use (or not) here. Either the install succeeded, or it failed as it was requested with the various flags. The text output is just because CLI users are expecting a UI update of some form so that they know that the command didn't hang, or fail silently. VSCode can act on swiftly's behalf to present a message after it completes successfully.
suggestion: Implement a progress file flag on the install subcommand, so that VSCode can set up a file/pipe and be able to present a progress indicator for the user. The toolchain downloads can be slow over some internet connections.
suggestion: A really big part of installing toolchains on Linux is making sure to install any system packages that Swift needs to be present on the system. I think that this should be called out in this proposal explicitly. There is a "post-install" file option on the install subcommand that should be useful here, as swiftly will emit (only if it is actually needed) a command that will install all of the missing packages. Note that this command needs to run as root, so VSCode would need to facilitate running it as root for Linux users. As I understand it there is precedent for VSCode prompting the user for their "sudo" password, and running a command elsewhere. Care should be taken here by VSCode to only run expected command patterns as root, such as apt-get -y install x y z ... or yum install a b c.
The extension should detect if the current project contains a .swift-version file. If yes, install the Swift toolchain if is not already present or switch to the given toolchain in VSCode.
suggestion: I think it will be important to monitor this file too, and do these kinds of checks and potential installations (only if it isn't already installed) whenever that happens. For example, the user could have git pull -ed some changes Note that if the toolchain changes, then it's possible that the extension will need to restart VSCode so that Sourcekit-LSP and other services are in sync with the current toolchain. I expect that this could be a significant effort to get it working correctly.
If not present, the user should be able to install Swiftly from VSCode Extension
thought: When installing swiftly using the init subcommand, swiftly can be installed in non-standard locations using the SWIFTLY_HOME_DIR and SWIFTLY_BIN_DIR environment variables. I wonder if the VSCode extension should ask the user if they want to customize these, or should it tell them that it will go in the default location.
suggestion: Before swiftly init proceeds at the command-line it gives a summary of what's about to happen to their environment, and y/n prompt so that the user can abort. I expect that this kind of summary and prompt will need to be replicated in the VSCode extension for this.
thought: I wonder if the init subcommand can structure the summary in some way for the VSCode extension so that it can pick the parts that are relevant for the GUI (e.g. welcome message, swiftly home directory location, swiftly bin directory location, and profile updates), and skip the ones that may not be relevant, such as the shell followup items.
1 Like
Hi @cmcgee1024
I went through your suggestions and made the necessary changes to the doc. Please take another look.
Corrected the term.
Removed the success and error from the payload; will depend on exit status for success and error.
Yes, I've included the skip-install flag.
I have added this to List Toolchains to be consistent with ListAvailable Toolchains because I plan to use the same structure in both.
I removed the payload so that it will depend solely on status codes.
We will add a new CLI parameter called --progress-file, which takes a file and appends progress info as JSON objects separated by new line in JSONNL format
Added a post-install-file option when installing the toolchains.
Questions: Do we always need a root here? If so, how do we run something for MacOS? In Linux, pkexec allows running commands as root noninteractively, and sudo requires a running tty.
We will monitor this file using a FileSystemWatcher, which is provided by VSCode to subscribe to file updates.
I have changed the installation flow to include a confirmation step. The user can change SWIFTLY_HOME_DIR and SWIFTLY_BIN_DIR or continue with the defaults.
2 Likes
@roulpriya this is really coming together.
Do we always need a root here? If so, how do we run something for MacOS? In Linux,
pkexecallows running commands as root noninteractively, and sudo requires a running tty.
Yes, swiftly only creates a post installation file if there are things that it cannot do itself without escalating its privilege. Agreed that sudo is likely to require the user's password. Question is there an established way to handle this in VSCode already? Can this mechanism be used for this purpose?
Implementation Overview:
suggestion: Add bullet items in the list to mention how exit codes of non-zero, text coming from standard error (e.g. warnings, and errors) will be handled. Maybe they go to some VSCode console view, or error log to help with diagnoses?
suggestion (non-blocking): I think that JSONNL should be JSONL or JSON Lines. Same with the file extensions in the examples, they should be .jsonl with a single 'n'.
nit: –progress-file=... should have two minuses, not just the one
- If the post-install script requires elevated permissions, we will need to wrap the execution under an appropriate helper such as pkexec, etc.
suggestion: The post-install script by swiftly's definition will require elevated privileges to run. I would call that out, and also I suggest that the VSCode extension check the file using an "allow-list" of potential command sequences. For example, a starting allow list would be something like apt-get -y install( (\[A-Za-z0-9\-]+))+ and yum install( [A-Za-z0-9\-]+)+ to check that unexpected root-level commands are being passed through the VSCode extension. Additional items can be added to the list over time if new Linux distributions are added to the supported list.
After installation is completed, we will run swiftly init --verbose --assume-yes --skip-install to initialize Swiftly itself and show the output in a output window
suggestion: This is one of the steps called out in the automated install instructions. I would call this out as the way that swiftly will be installed in the system. After this, the VSCode extension will install a swift toolchain using swiftly (probably swiftly install latest), but with the progress file and post installation parameters so that it can show the user the progress, and also perform post-installation steps as root.
1 Like
@cmcgee1024 I have updated the doc with your suggestions.
I have added a new section on error handling and logging as they are same for all the commands.
We will be showing notifications on error and maintain a swiftly channel for logging output.
I have updated all the suggested points. Regarding the post-install file
- We will also check the file using an allow-list of command regex to validate the commands before execution and show the summary to the user before running the scripts.
- The post-install script requires elevated permissions to run
- we will use
pkexecin linux to run the script as root. - In macOS we have the option to either create an AppleScript to trigger system authentication dialogs and run it using
osascriptOR we can create a helper application similar topkexecfor macOS to handle the root level access using macOS Authorization Services framework to request privileges osascriptis also used by other IDE’s like JetBrains and is also simpler to implement. The helper application would need code signing and entitlements and some other customization to the build steps of the extension.- Currently there is no post-install script for macOS so we can even skip this.
- we will use
Added this step as well.
1 Like
@roulpriya this looks great!
2 Likes
Hi @cmcgee1024
Are there any issues I can work on?
Also, can you please provide your input here: Add lock to ensure only one Swiftly process is running at any point · Issue #142 · swiftlang/swiftly · GitHub
Hi @roulpriya congrats on joining GSoC!
1 Like
Thank you for this great opportunity. I’m really excited to be a part of the Swift community. Looking forward to contribute.
1 Like