[Review] SE-0085: Package Manager Command Names

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 < swift-evolution@swift.org> 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 < > swift-build-dev@swift.org> wrote:

> On 9 May 2016, at 23:05, Daniel Dunbar via swift-build-dev < >> swift-build-dev@swift.org> 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
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

--
Ankit

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution