[GSoC-2023] Customizable(and interactive) package templates proposal

[Howard_Chu]

Thank you so much for your reply, Ashley. First of all, I would love to work with you!

@bitjammer

I would encourage you to think of ways where someone does not need to pass a template description at all. That is, once a template is installed, the user shouldn't have to think about where it is installed unless something has gone wrong. I could see passing a template as a power-user ability or for testing template development, though!

I fully agree that the swift package template command should be used to store the template in a fixed location, so that it can be used directly when initializing in the future (e.g. swift package init). And the --template option seems completely unnecessary, after all it does the same thing as --type. I am sorry that the design is so complicated and unnecessary.

@bitjammer

The interaction for the package type might use some tweaking visually, but overall looks reasonable. I would personally lean on that and make it fast to get through with reasonable and stable defaults, like not including tests by default for some package types.

Sure, I think tweaking is definitely needed, this is only the simplest version implemented for demonstration purposes.

@bitjammer

I would personally not want to see another swift-based description format and especially not for this. If you require structured data for the description, I would suggest just making it JSON as it's easier to read and encode/decode.

After thinking about it, I also think that such a format is not necessary. The reason I thought so is that in the official idea list (probably written by boris), it says "In this project, we will define a format for templates", which I thought was a way to package all the code and folders in a project into a single file. In fact, a zip file with a template.json file describing the interactivity (e.g., specifying the location of the test folder) would solve the problem perfectly, and would be much simpler to use.

I am sorry for this design mistake, as I started writing the proposal very late due to health issues, so I did not get enough feedback.

If that's so, there is only one use for this command, swift package template </path/to/your/project>, that is to copy the project as a template into a pre-defined fixed location for the user to call init later. As for sharing, users can just send zip files to each other directly. (just like downloading a template from some iOS App Templates websites) The only thing that is worth mentioning is that the root path of the project can contain a template.json file for possible interactions.

@bitjammer

What ultimately drives the list of possible dependencies and why would you say it is customizable? What are the most common packages that would be included and in what scenarios?

I'm sorry to have to say that I don't know. I don't think it's so difficult to write Package.swift files by hand that you need to include dependencies interactively. Moreover, when users can design their own templates, they can modify the Package.swift file first and then use the swift package template to store it for future use. If you say that writing Package.swift is too difficult for newcomers, it is better to include dependencies interactively, but how will newcomers know which dependencies to include, and which not to include? So I don't think interactive include dependencies is a necessary feature. Sorry, I'm kinda limited by the description in the idea list.

@bitjammer

Again, unless there needs to be code execution in the template itself, I don't see a need to use Swift source code to define this. Whether it's source files, the resulting Package.swift manifest, or even empty directories, can the template's contents simply be a directory of files, plus a JSON description, that can be modified before being copied into place? I think it's great to leave the door open for more complex needs in the future, but better to start this off humbly in terms of complexity if we can. For example, perhaps we can utilize installable SwiftPM plugins in the future for more complex functionality .

Definitely, I think this is the best approach. Customize is entirely the user's job and swiftPM only helps store it in a fixed place for quick initialization, with some interactivity like whether to add the test folder or not.

@bitjammer

Instead of a PDF, in the future would you please share a Markdown file, perhaps in a GitHub gist or something, with more details with what you're thinking? It makes it easier for folks to access.

Of course, I'll write up a markdown file and make it available soon.

@bitjammer

Nice job prototyping this! Looking forward to seeing further refinements.

Thank you very much, although I think most of my proposals are too complex and lack practicality, I am sorry for not thinking about the problem properly, and I promise to iterate quickly.

Also, I don't really understand what real practical interactivity there is, other than whether to include the test folder or not. I'll create a post asking for opinions on the forum.