I'm Niko, I graduated as a software engineer last year. I'd be very happy to work on templates support for SwiftPM as part of GSoC 2022! I'm proficient in Swift and have used it for both iOS & macOS development as well as for a server-side project with Vapor.
I think it would be great to provide the ability to create new packages from templates, as was also already pitched in this forum post and this evolution proposal. This could help organizations standardize their directory structure across projects. It would also allow projects like Vapor to offer templates so that people could easily get started with a new project. Vapor currently does this through their CLI tool but having templating built into the package manager would make this capability more readily available, also to smaller open source projects and individuals.
I would be happy to build on top of the existing pitch and feedback, and look at package managers from other ecosystems, such as Node's npm, Rust's Cargo etc. to further flesh out the idea and implement it in an intuitive way.
@NeoNacho @abertelrud @tomerd you were mentioned as potential mentors for this project. Do you know whether any work has been done on this topic since May of last year?
I'm really looking forward to getting more involved in the Swift community!
Thanks for reaching out @PoshAlpaca. Starting from the existing pitch and proposal is a good starting point. with the new SwiftPM plugin subsystem there is also an opportunity to explore if this can be abstracted as a new template type.
Hi @tomerd, thanks for the quick reply! Ah that's super interesting, I hadn't looked too close at the plugin feature yet. But with
CommandPlugin one can actually already build an initialization plugin, it would just currently take the extra step of initializing a Swift package and adding the plugin's package as a dependency before being able to run it.
Would be cool to potentially expand on that for the templating system!
Exploring if we can use the commands plugin as-is for this usage is interesting! If not powerful / flexible enough, we can consider adding a new plugin type dedicated to this purpose, tho would be good to not need to introduce such complexity.
cc @abertelrud @NeoNacho for additional design ideas.
Sorry for being unresponsive. I unfortunately won't be able to take part in the GSoC after all. I received a job offer that is very interesting for me and it would sadly not be feasible to do both.
All the best to the GSoC participants! I'm really looking forward to see what comes out of it.
Thanks for the heads up, best of luck and hope to see you around in the Swift community sometime again