or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
+1 This proposal makes the package manager a first-class tool, instead of a set of command options.
* Is the problem being addressed significant enough to warrant a change to Swift?
It should be addressed before it goes public.
* Does this proposal fit well with the feel and direction of Swift?
Yes.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I'm used to using npm, pod, gem, bundle. So I think I would have preferred a spm command. It would also have made commands shorter to type. But I guess the proposal makes more sense for Swift.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Serious read.
···
More information about the Swift evolution process is available at
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...
···
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:
* What is your evaluation of the proposal?
These sound great! +1. Subcommands, even nested ones like `swift package init`, are more solid and easier to remember.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes, I think establishing a clear system is important.
* Does this proposal fit well with the feel and direction of Swift?
Yes
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve used `npm`, which has similar subcommands and shortcut methods.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick reading
···
On 10 May 2016, at 8:05 AM, Daniel Dunbar via swift-evolution <swift-evolution@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:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
We discussed at length the `spm` and `swiftpm` alternatives raised on this thread. In the end, we chose not to go that direction with the proposal for the reasons I included. We do recognized the desire for a shorter command, and view having an alias as something that can be added later if it proves to be the right thing to do.
Thanks!
- Daniel
···
On May 9, 2016, at 3:05 PM, Daniel Dunbar via swift-evolution <swift-evolution@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:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I agree with the review feedback so far, it's a good proposal. But just as
David mentioned, I think a `spm` command, which would just be an alias for
`swift package` would work really well. `spm build`, `spm test` all feel
very in line with existing tools like gem, npm, pod etc. I think those ~3
letter commands are very short for a good reason. And with the entrance of
Swift on the server, having to write `swift package X` right next to the
rest of the "3-letter" tools could feel like an oversight.
I absolutely agree that for the sake of discoverability and clarity, the
`swift package` command should be the canonical way. And in addition to
that, I suggest we add `spm` to better fit into the CLI-driven world and
save people quite lot of typing.
Honza
···
On Tue, May 10, 2016 at 8:21 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote:
> * What is your evaluation of the proposal?
+1 This proposal makes the package manager a first-class tool, instead of
a set of command options.
> * Is the problem being addressed significant enough to warrant a
change to Swift?
It should be addressed before it goes public.
> * Does this proposal fit well with the feel and direction of Swift?
Yes.
> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
I'm used to using npm, pod, gem, bundle. So I think I would have preferred
a spm command. It would also have made commands shorter to type. But I
guess the proposal makes more sense for Swift.
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
+1 to `swift package` being a little too verbose. However, I like the
alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I
have already been referring to the package manager as SPM, so IMO that name
does not lose out on any clarity while also allowing it to be terse enough
for every day use.
I would not be against having both `spm` and `swift package` as Honza
suggested.
···
On Mon, May 9, 2016 at 11:50 PM Honza Dvorsky via swift-build-dev < swift-build-dev@swift.org> wrote:
I agree with the review feedback so far, it's a good proposal. But just as
David mentioned, I think a `spm` command, which would just be an alias for
`swift package` would work really well. `spm build`, `spm test` all feel
very in line with existing tools like gem, npm, pod etc. I think those ~3
letter commands are very short for a good reason. And with the entrance of
Swift on the server, having to write `swift package X` right next to the
rest of the "3-letter" tools could feel like an oversight.
I absolutely agree that for the sake of discoverability and clarity, the
`swift package` command should be the canonical way. And in addition to
that, I suggest we add `spm` to better fit into the CLI-driven world and
save people quite lot of typing.
Honza
On Tue, May 10, 2016 at 8:21 AM David Hart via swift-evolution < > swift-evolution@swift.org> wrote:
> * What is your evaluation of the proposal?
+1 This proposal makes the package manager a first-class tool, instead of
a set of command options.
> * Is the problem being addressed significant enough to warrant a
change to Swift?
It should be addressed before it goes public.
> * Does this proposal fit well with the feel and direction of Swift?
Yes.
> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
I'm used to using npm, pod, gem, bundle. So I think I would have
preferred a spm command. It would also have made commands shorter to type.
But I guess the proposal makes more sense for Swift.
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
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
···
On May 10, 2016, at 12:42 AM, 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:
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`!
+1 to `swift package` being a little too verbose. However, I like the alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have already been referring to the package manager as SPM, so IMO that name does not lose out on any clarity while also allowing it to be terse enough for every day use.
I would not be against having both `spm` and `swift package` as Honza suggested.
+ 1 to the proposal in general and also to adding the `spm` alias.
···
On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, May 9, 2016 at 11:50 PM Honza Dvorsky via swift-build-dev <swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>> wrote:
I agree with the review feedback so far, it's a good proposal. But just as David mentioned, I think a `spm` command, which would just be an alias for `swift package` would work really well. `spm build`, `spm test` all feel very in line with existing tools like gem, npm, pod etc. I think those ~3 letter commands are very short for a good reason. And with the entrance of Swift on the server, having to write `swift package X` right next to the rest of the "3-letter" tools could feel like an oversight.
I absolutely agree that for the sake of discoverability and clarity, the `swift package` command should be the canonical way. And in addition to that, I suggest we add `spm` to better fit into the CLI-driven world and save people quite lot of typing.
Honza
On Tue, May 10, 2016 at 8:21 AM David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> * What is your evaluation of the proposal?
+1 This proposal makes the package manager a first-class tool, instead of a set of command options.
> * Is the problem being addressed significant enough to warrant a change to Swift?
It should be addressed before it goes public.
> * Does this proposal fit well with the feel and direction of Swift?
Yes.
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I'm used to using npm, pod, gem, bundle. So I think I would have preferred a spm command. It would also have made commands shorter to type. But I guess the proposal makes more sense for Swift.
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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`!
It "should" be `swift package-manager` or `swift pm` as we're operating on the package manager, not on our swift project directly. i.e. `swift package-manager init` or `swift pm generate-xcodeproj` work because the verb is the third parameter, not the second. When we have two verbs, such as `swift package generate-xcodeproj`, it doesn't read well to me at all.
The space between `swift` and `package-manager` (or `pm`) is a bit inelegant and only exists in order to shoehorn this into the `swift` metatool. To my mind, it shows that this functionality would be better off as its own top level command: `swiftpm` being the obvious one, though `spm` also works.
For what's worth, I'm not a fan of creating a solution that a sizeable proportion of people feel the need to alias. Aliases should never be used in documentation, but do end up being passed around by team members as they are pasted into tools like Slack or Wikis and then cause confusion.
Regards,
Rob...
···
On 10 May 2016, at 16:38, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On May 10, 2016, at 12:42 AM, Rob Allen via swift-build-dev <swift-build-dev@swift.org> wrote:
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.
Are there any commands to `swift` that are not package manager commands? If not, then another option is to move all the package manager operations to top level commands of `swift`. e.g. `swift init`, `swift generate-xcodeproj` etc. This solves the discoverability and tab completion between `swift` and `swiftpm` problem completely, and also makes for a sane api of:
As an aside, anone of the subcommands to `swift` are discoverable because `swift -h` displays "OVERVIEW: Swift compiler" and doesn't imply that it does anything different to `swiftc` which also says "OVERVIEW: Swift compiler" when you do `swift -h`, but has a different set of options :)
···
On 10 May 2016, at 16:38, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On May 10, 2016, at 12:42 AM, Rob Allen via swift-build-dev <swift-build-dev@swift.org> wrote:
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.
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`!
Question for those of you who are advocating for a "spm" alias: Do you have a strong argument / preference for "spm" vs "swiftpm"? Personally I have been abbreviating the project as "swiftpm" and not "spm" when I talk about it, and have been trying to push that as the preferred abbreviation. "spm" is a few less keystrokes, but is a much more generic, less googleable name; out of context, it's impossible to know what it refers to. Once the project gets enough mindshare, like "npm" has, that might be less of an issue, but I still personally prefer the more descriptive "swiftpm". Thoughts?
- Rick
···
On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev <swift-build-dev@swift.org> wrote:
On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to `swift package` being a little too verbose. However, I like the alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have already been referring to the package manager as SPM, so IMO that name does not lose out on any clarity while also allowing it to be terse enough for every day use.
I would not be against having both `spm` and `swift package` as Honza suggested.
+ 1 to the proposal in general and also to adding the `spm` alias.
On May 10, 2016, at 9:38 AM, Rick Ballard via swift-build-dev <swift-build-dev@swift.org> wrote:
On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev <swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>> wrote:
On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to `swift package` being a little too verbose. However, I like the alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have already been referring to the package manager as SPM, so IMO that name does not lose out on any clarity while also allowing it to be terse enough for every day use.
I would not be against having both `spm` and `swift package` as Honza suggested.
+ 1 to the proposal in general and also to adding the `spm` alias.
Question for those of you who are advocating for a "spm" alias: Do you have a strong argument / preference for "spm" vs "swiftpm"? Personally I have been abbreviating the project as "swiftpm" and not "spm" when I talk about it, and have been trying to push that as the preferred abbreviation. "spm" is a few less keystrokes, but is a much more generic, less googleable name; out of context, it's impossible to know what it refers to. Once the project gets enough mindshare, like "npm" has, that might be less of an issue, but I still personally prefer the more descriptive "swiftpm". Thoughts?
Pro:
* Easier to google
* Easier to read and mentally parse
* Does not look like luncheon meat
Con:
* Harder/longer to type
* Has no catchy Monty Python songs
-- E
···
On May 10, 2016, at 10:38 AM, Rick Ballard via swift-build-dev <swift-build-dev@swift.org> wrote:
On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev <swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>> wrote:
On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to `swift package` being a little too verbose. However, I like the alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have already been referring to the package manager as SPM, so IMO that name does not lose out on any clarity while also allowing it to be terse enough for every day use.
I would not be against having both `spm` and `swift package` as Honza suggested.
+ 1 to the proposal in general and also to adding the `spm` alias.
Question for those of you who are advocating for a "spm" alias: Do you have a strong argument / preference for "spm" vs "swiftpm"? Personally I have been abbreviating the project as "swiftpm" and not "spm" when I talk about it, and have been trying to push that as the preferred abbreviation. "spm" is a few less keystrokes, but is a much more generic, less googleable name; out of context, it's impossible to know what it refers to. Once the project gets enough mindshare, like "npm" has, that might be less of an issue, but I still personally prefer the more descriptive "swiftpm". Thoughts?
+1 to `swift package` being a little too verbose. However, I like the alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have already been referring to the package manager as SPM, so IMO that name does not lose out on any clarity while also allowing it to be terse enough for every day use.
I would not be against having both `spm` and `swift package` as Honza suggested.
+ 1 to the proposal in general and also to adding the `spm` alias.
Question for those of you who are advocating for a "spm" alias: Do you have a strong argument / preference for "spm" vs "swiftpm"? Personally I have been abbreviating the project as "swiftpm" and not "spm" when I talk about it, and have been trying to push that as the preferred abbreviation. "spm" is a few less keystrokes, but is a much more generic, less googleable name; out of context, it's impossible to know what it refers to. Once the project gets enough mindshare, like "npm" has, that might be less of an issue, but I still personally prefer the more descriptive "swiftpm". Thoughts?
I prefer spm. Given the sponsorship by Apple I think mindshare is a matter of time. That said, I wouldn't oppose swiftpm either if that has more support.
···
Sent from my iPad
On May 10, 2016, at 11:38 AM, Rick Ballard <rballard@apple.com> wrote:
On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev <swift-build-dev@swift.org> wrote:
On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution <swift-evolution@swift.org> wrote:
I agree, I think just `swiftpm` is a great mix of ease of use and discoverability, for exactly the reasons you propose. I’ve been trying to always use that when talking about Swift Package Manager for the last few months.
I think this is also better than `swift xxx` due to swiftpm really being a different user context from `swift` commands. Yes, under the hood it’s doing swift-y things, but package management is not compiling.
On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev <swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>> wrote:
On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 to `swift package` being a little too verbose. However, I like the alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have already been referring to the package manager as SPM, so IMO that name does not lose out on any clarity while also allowing it to be terse enough for every day use.
I would not be against having both `spm` and `swift package` as Honza suggested.
+ 1 to the proposal in general and also to adding the `spm` alias.
Question for those of you who are advocating for a "spm" alias: Do you have a strong argument / preference for "spm" vs "swiftpm"? Personally I have been abbreviating the project as "swiftpm" and not "spm" when I talk about it, and have been trying to push that as the preferred abbreviation. "spm" is a few less keystrokes, but is a much more generic, less googleable name; out of context, it's impossible to know what it refers to. Once the project gets enough mindshare, like "npm" has, that might be less of an issue, but I still personally prefer the more descriptive "swiftpm". Thoughts?