I agree with Rob and Ankit, with one detail: I'd expect `spm` to print the help section, instead of building (just like npm, nvm, gem, pod etc).
On Tue, May 10, 2016 at 10:31 AM Ankit Agarwal via swift-evolution < [email protected]> wrote: > +1 to spm or swiftpm (in that order) > As a swiftpm user I would imagine it works like : > spm -> builds > spm test -> runs tests > spm init -> new project > > On Tue, May 10, 2016 at 1:12 PM, Rob Allen via swift-build-dev < > [email protected]> wrote: > >> >> > On 9 May 2016, at 23:05, Daniel Dunbar via swift-build-dev < >> [email protected]> wrote: >> > >> > Hello Swift community, >> > >> > The review of "SE-0085: Package Manager Command Names" begins now and >> runs through May 12. The proposal is available here: >> > >> > >> https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md >> > >> >> >> Hi, >> >> I like this proposal a lot as the functionality switches to swift build >> feel like bolt-ons and we're already up to four of these, so it's probably >> not sustainable long term as SPM evolves. >> >> I'm not totally sold on `swift package` as the new command though as >> "package" is an imperative verb like "build" or "test" and implies that if >> I run it, then it will generate a "package" whereas it will actually do >> nothing as an additional switch will be required. This requirement to >> always take a second sub-command makes it different from `swift build` and >> `swift test` too. Are there any commands to `swift` current that require a >> sub-command to work? >> >> Maybe it would be better for the package manager to be separate from the >> swift command? If separate, the obvious name would be `spm` as that's what >> we all call it anyway. `swiftpm` as noted in the alternatives section would >> also work. If we have to have it as a subcommand of `swift` then, I'd >> rather have `swift pm` as that way the command is obviously the third word >> in `swift pm init`. >> >> >> I would also prefer to remove the subcommand flags from `swift build` at >> the same time as when this change lands rather than delayed. That way it >> all happens in one go rather than as two stages which means only one >> announcement point is needed. The band-aid has to be ripped off at some >> point as `swift build --init` won't work in v3, so better for it to be gone >> before new developers find it during when downloading the preview released >> and then have to learn the new way. >> >> >> Finally, having raised my concerns, I'd like to emphasise that I'm very >> much in favour of this proposal and would prefer it to be accepted as-is >> rather than be rejected as I really dislike the current sub-command flags >> to `swift build`! >> >> >> Regards, >> >> Rob... >> > _______________________________________________ >> > >> swift-build-dev mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-build-dev >> > > > > -- > Ankit > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
