[swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names
czechboy0 at gmail.com
Tue May 10 04:04:46 CDT 2016
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 at 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 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:
>> 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`!
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution