[swift-build-dev] Project init command

Lander Brandt landerbrandt at gmail.com
Sat Dec 5 15:23:11 CST 2015


Interactive by default would definitely be better for newcomers. I’ll see about submitting a formal proposal soon although it may not appear until after this upcoming Wednesday as I have university finals that are slightly higher priority.

> On Dec 5, 2015, at 13:17, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
> 
>> 
>> On Dec 5, 2015, at 1:15 PM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>> 
>> This is indeed something we have discussed and agree it would make sense to add, just haven't gotten there yet.
>> 
>> Patches in this direction are welcome, although I recommend as with any new feature coming up with a concrete proposal and outline before you set in on the implementation...
>> 
>>> On Dec 5, 2015, at 1:01 PM, Lander Brandt via swift-build-dev <swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>> wrote:
>>> 
>>> On the Swift package manager page on swift.org <http://swift.org/> (https://swift.org/package-manager/#example-usage <https://swift.org/package-manager/#example-usage>) the requirements for creating a package/application are clearly outlined, but why not include a command in the swift tool for autogenerating the require? I did a quick look and didn’t see any existing discussion, so I apologize if this has already been discussed.
>>> 
>>> Example of the tool command: `swift init foo --type=(lib|app)`
>> 
>> One question we would need to resolve is whether or not the tool should be interactive. If one goal
> 
> To finish my thought:
> 
> If one goal of the tool is to help out newcomers, it might make sense for the default invocation to be interactive with command line prompts, and then provide options which advanced users can use to efficiently create new projects.
> 
>  - Daniel
> 
>>> 
>>> Would create a new directory called “foo” with the following tree structure for a project of type app:
>>> 
>>> foo
>>> ├── Package.swift
>>> ├── Packages
>>> ├── README.md
>>> └── main.swift
>> 
>> This is most likely not the initial layout we want to recommend, because it is less obvious how to migrate upwards. This flat layout is a little confusing as well to newcomers because Package.swift here *isn't* part of their actual larget. We included support for this style for "micro-framework" type packages, where it can be useful for the simplicity of the project to be obvious in the initial repo view, but this is something more advanced users can come to discover.
>>> 
>>> And for project of type lib:
>>> 
>>> foo
>>> ├── Package.swift
>>> ├── README.md
>>> └── Sources
>>>     └── Foo.swift
>>> 
>>> In both cases Package.swift would contain something basic like:
>>> 
>>> import PackageDescription
>>> 
>>> let package = Package(
>>>     name: “Foo",
>>>     dependencies: [
>>>     ]
>>> )
>> 
>> I'd probably leave dependencies: out of this. I presume you added it to help people know where to add things, but another related thing we would like to see develop is tools for automatically editing this file (e.g., a command to add a new dependency). Tools like that will help people get their manifest files right w/o needing to memorize the package syntax.
>> 
>>  - Daniel
>> 
>>> 
>>> _______________________________________________
>>> swift-build-dev mailing list
>>> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
>> 
>>  _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org <mailto:swift-build-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-build-dev <https://lists.swift.org/mailman/listinfo/swift-build-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20151205/83248cf1/attachment.html>


More information about the swift-build-dev mailing list