My name is Daniel Barychev and I am a Carnegie Mellon University sophomore looking to work with Swift for GSoC. I am particularly intrigued by the project ideas for the Swift Package Manager as I actually have some experience working with that technology before. Specifically, I spent last summer at IBM on the Swift@IBM team working on a security framework for SwiftPM that my team presented to @rballard and @ddunbar. I would love to work on some of the security features that I was working with then once more from the Swift team’s perspective, but some of the ideas presented on the project ideas page seem great so I wanted to ask some questions about them before I submit a proposal.
The idea that intrigues me most is the one pertaining to mechanically editing the Package.swift file. I spent a lot of time last summer dealing with semantics related to how the file was formatted and the versions of the dependencies it was trying to resolve so a CLI based editor for the file sounds like a fantastic idea. I have spent some time looking through SourceKit and the offerings it has towards cursor based approaches to refactoring, mainly consulting this. It seems like the ResolvedCursorInfo object and implementation of the performChange method may be of the biggest assistance towards trying to extend the refactoring principles towards the intended goal. I did, however, note that Ankit mentioned in a previous post that the libSyntaxSwiftSyntax library may be more applicable towards the desired mechanization, but that it’s technical feasibility is a concern. I was just wondering if I’m thinking in the right direction and if any consensus has been reached as to which tool should be looked at most carefully.
In addition, as noted in the aforementioned post, the project idea towards suggesting semver tags does seem very connected to the Package.swift mechanization concept as it would be a perfect example of the type of mechanization we would want to implement. I bring this up because I am generally interested in the type of mechanizations the Swift team would like to see supported in an MVP or in a final product. It was mentioned that an MVP would modify simple manifests with declarative syntax, but I’m not sure what changes these modifications would entail towards the dependencies, targets, and products.
With respect to the semver project idea, I looked through SourceKitten as Ankit suggested in another post. I mostly tried its structure command on various dependencies and I can definitely see why this would be a great tool to employ in trying to diff various versions to determine if a major change to the API has been made. I believe, however, that a tool like this can also be extended to the considerations of the mechanization project in that we can specify something we wish to change in the Package.swift file and assistance is given in locating that without us specifying a cursor location. Would that be a reasonable connection to make or do we need something fundamentally different?
Lastly, thank you to all contributing to the Swift open source community. It was great consulting all of the available resources in my position last summer and I hope to be able to play an even more in depth role in the Swift community in this one.
Great! Please note that you're free to submit proposals that are not from the project ideas page!
I discussed SwiftSyntax with Xi today and we think it makes sense to use that instead of SourceKit for our use case.
The semver idea has a little different requirements than the editing idea. For semver, we need to look at the public interfaces vended by a package and require no source mutation. If I understand correctly, this will not be possible with SwiftSyntax (or will be difficult to do).
An MVP for editing manifest would entail creating command line interface for mutating the targets, products and package dependencies. Some examples:
$ swift package add target Foo --type library --with-tests
This will create two targets Foo and FooTests, and add corresponding entries in the Package.swift file.
$ swift package rename target Foo Bar
$ swift package add dependency https://github.com/apple/swift-nio --latest-major-version
Absolutely. SourceKit is a powerful tool that can be used by SwiftPM to build complex features in future. However, as mentioned above, we want to use SwiftSyntax for implementing the mechanical edit idea.
Thank you so much Ankit! Your response definitely answered my questions and I'll be sure to look much further into SwiftSyntax. I'll try to structure my proposal with respect to the types of CLI commands you mentioned as well.
@DanBarychev The following project generates API diffs thanks to SourceKit (through SourceKitten). It might be a good starting point to research the GSCO semver project: