Sorry for replying late this week due to schoolwork.
It's entirely possible. For newcomers, I would think it may not be too easy to find the location(s) (finding such location(s) most likely requires reading the documentation, or print it out using the --help command option). This is where I think @sebsto's idea may come in handy. If swift package init can support cloning a remote project using URL, it can be quite easy to use. If so, for ease of understanding, do you think we should add a --url option for using remote templates, or stick with --type? The difference between an init command and git clone will be that init command can decode the config file and enters interactive mode.
I will definitely look into it, i think it's a great idea. I could also imagine power users creating highly customized templates that can quickly include different types of dependencies, for it can be faster interactively than to rewrite Package.swift every time. What do you think?
It's a great way of thinking about it. Although some of the arguments may go beyond the scope of this projects(customizable templates), I think it's definitely worth consideration.
Starting with the basic swift package init we got these arguments:
--type <type> Package type: (default: interact)
library - A package with a library.
executable - A package with an executable.
tool - A package with an executable that uses
Swift Argument Parser. Use this template if you
plan to have a rich set of command-line arguments.
build-tool-plugin - A package that vends a build tool plugin.
command-plugin - A package that vends a command plugin.
macro - A package that vends a macro.
empty - An empty package with a Package.swift manifest.
--name <name> Provide custom package name
--version Show the version.
-h, -help, --help Show help information.
Obviously, no one has interest in interacting with --version or --help, which leaves us with --type and --name. Making --type interactive is a must-have, but --name is interesting. In the past, it was customary to create a folder manually and then cd and init. The process of creating a folder can be omitted by interacting with --name, which is also the approach of many project initialization tools. This idea was mentioned by @Diggory and @hassila in Update to swift package init templates. I personally like this idea too, it would be a nice experience if swiftPM automatically creates the project folder with users only have to enter the project name.
Another potential interaction is adding plugins like swift-docc-plugin or custom plugins by specifying path, which has also been mentioned in the post above and by @filip-sakel, so I'm only recapping it.
I will continue to write a markdown file to elaborate on the details while updating my proposal. Thank you for your response.