Add --init mode as proposed in SR-353

[brinsche]

swift build —initializes a new swift project with the following structure.

├── .gitignore
├── Package.swift
├── Sources
│   └── main.swift
└── Tests

.gitignore content:

.DS_Store
/.build
/Packages

Package.swift content:

import PackageDescription

let package = Package(
    name: "foo"
)

where foo is the name of the working directory

main.swift content:

print("Hello, world!")

Discussion points

Naming

maybe —create or —new would work too, but I prefer —init

VCS

the current implementation just creates a .gitignore for convenience, but we might want to discuss that

[mxcl]

Good start, thanks. I'll merge soon.

[Danappelxx]

I really don't like that commands are being slapped on to swift build - the Swift Package Manager really needs its own binary (i.e. spm build), otherwise it just feels really weird using it.

Some examples to demonstrate my point:

Create a new project
spm new
vs
swift build --init

Create a new project with the name "foo"
spm new foo
vs
swift build --init --name="foo"

Create a new project named foo with tests set up
spm new foo --with-tests
vs
swift build --init --name="foo" --with-tests

These examples may seem convoluted, but they apply in other places as well.

Pull dependencies without building
spm get or spm checkout
vs
swift build --get-only or swift build --checkout-only

Run tests
spm test
vs
swift build --test

Run the compiled binary
spm run
vs
swift build --run

Remove build artifacts
spm clean
vs
swift build --clean

It's not a huge deal from a user perspective, but as features are added onto SPM, it doesn't make a lot of sense to pile them into a subcommand.

Alternatively, swift build could be replaced with swift spm <build/test/get/etc>, and I would be perfectly fine with that.

Perhaps I should leave my notes elsewhere.

[brinsche]

While I agree that the naming needs some more thought, this commit does not add much more complexity since it's independent of what swift build is called. I think this discussion is more suited for the mailing list or maybe someone could write up a swift-evolution proposal.

[brinsche]

Are there any more concerns related to this commit? Anything I should change?

[mxcl]

Can we move the main code into a new file, call it whatever.

[brinsche]

Sorry, what exactly do you mean by that? Refactor the init case body into its own file, like usage.swift, or do you mean the generated main.swift?

[mxcl]

Yes, refactor the init case into its own file, stick the code in a function.

Thanks! 👍🏻

[brinsche]

Done!