[swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

Daniel Dunbar daniel_dunbar at apple.com
Tue May 10 10:38:19 CDT 2016


> On May 10, 2016, at 12:42 AM, Rob Allen via swift-build-dev <swift-build-dev at swift.org> wrote:
> 
> 
>> On 9 May 2016, at 23:05, Daniel Dunbar via swift-build-dev <swift-build-dev at 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?

I agree with this part about package sounding like an imperative verb. Do you have an alternative proposal that you like better, though? In practice, this confusion will be quickly mitigated as `swift package` simply shows the help.

> 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.

I agree.

(I'm not ignoring `spm` parts of your email, just plan to reply to them in bulk once we have received more feedback).

 - Daniel

> 
> 
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev



More information about the swift-evolution mailing list