I've been working on a SwiftPM executable (danger-swift
<https://github.com/danger/danger-swift>\) which is a pretty small CLI tool.
I feel like it's a bunch of work to allow a user to get a copy of the app
running on their computer / CIs. My current app distributions options are:
Homebrew <https://brew.sh> and Marathon
<https://github.com/JohnSundell/Marathon> (which I added to homebrew) or a
custom cURL'd setup script. None are great, because it requires many build
steps and require custom installers.
In an eco-system like Node/Ruby I can do something like "npm install -g
danger" which uses the centralized index, or "npm install -g
danger/danger-js" if I wanted to use a repo which would install CLI tools.
I'd like to see SwiftPM cover this part of the swift ecosystem, and
encourage building small CLI tools in swift.
So, as an example of behavior, running this new command: "swift install
danger/danger-swift" would:
- use the danger/danger-swift a shortcut for GitHub, and clone that repo
into a temporary folder
- parse the Package.swift
<https://github.com/danger/danger-swift/blob/master/Package.swift> then let
the user know they are going to install the CLI executable danger-swift
- run swift build in release mode
- install the executable into a folder in the users default path
This greatly reduces the friction to making more tools, and reduces the
number of dependencies for users to being the Xcode CLT which basically
everyone has out of the box.
I'm willing to take a stab at an implementation if this has approval of
Anders/Daniel.
I’m also very interested in that topic, and I have some info which might interest you:
I have been working on similar functionality, but at the local level (npm install danger & npm run danger). Part of the work I did was integrated in the Swift Package Manager for Swift 4 and the rest will probably get released with the next point release (i.e., Swift 4.1).
For the sake of demonstration, lets imagine we’re already using Swift 4.1. You can add danger-swift as a dependency in a Package.swift - you can even use an empty Package.swift:
As of Swift 4, swift run will only work for executable products defined in the current Package. But that will change in the next release.
Now, concerning global installation, I know that the Swift Package Manager team have already thought a lot about it, so it might be interested to see what they had in mind.
Regards,
David.
···
On 14 Sep 2017, at 19:15, Orta Therox via swift-build-dev <swift-build-dev@swift.org> wrote:
Hey all,
I've been working on a SwiftPM executable (danger-swift <https://github.com/danger/danger-swift>\) which is a pretty small CLI tool. I feel like it's a bunch of work to allow a user to get a copy of the app running on their computer / CIs. My current app distributions options are: Homebrew <https://brew.sh/> and Marathon <https://github.com/JohnSundell/Marathon> (which I added to homebrew) or a custom cURL'd setup script. None are great, because it requires many build steps and require custom installers.
In an eco-system like Node/Ruby I can do something like "npm install -g danger" which uses the centralized index, or "npm install -g danger/danger-js" if I wanted to use a repo which would install CLI tools. I'd like to see SwiftPM cover this part of the swift ecosystem, and encourage building small CLI tools in swift.
So, as an example of behavior, running this new command: "swift install danger/danger-swift" would:
- use the danger/danger-swift a shortcut for GitHub, and clone that repo into a temporary folder
- parse the Package.swift <https://github.com/danger/danger-swift/blob/master/Package.swift> then let the user know they are going to install the CLI executable danger-swift
- run swift build in release mode
- install the executable into a folder in the users default path
This greatly reduces the friction to making more tools, and reduces the number of dependencies for users to being the Xcode CLT which basically everyone has out of the box.
I'm willing to take a stab at an implementation if this has approval of Anders/Daniel.
We definitely want an installation story for SwiftPM. This is a pretty
complex topic because, currently, we don't have support for things like
resources, installing external dependencies, custom build requirement. That
said, we can probably start by building something for simple executable
packages. Before an implementation, we would need discuss a proposal and go
through the swift-evolution process. Feel free to start a draft on
swift-build-dev!
···
On Thu, Sep 14, 2017 at 10:45 PM, Orta Therox via swift-build-dev < swift-build-dev@swift.org> wrote:
Hey all,
I've been working on a SwiftPM executable (danger-swift
<https://github.com/danger/danger-swift>\) which is a pretty small CLI
tool. I feel like it's a bunch of work to allow a user to get a copy of the
app running on their computer / CIs. My current app distributions options
are: Homebrew <https://brew.sh> and Marathon
<https://github.com/JohnSundell/Marathon> (which I added to homebrew) or
a custom cURL'd setup script. None are great, because it requires many
build steps and require custom installers.
In an eco-system like Node/Ruby I can do something like "npm install -g
danger" which uses the centralized index, or "npm install -g
danger/danger-js" if I wanted to use a repo which would install CLI
tools. I'd like to see SwiftPM cover this part of the swift ecosystem, and
encourage building small CLI tools in swift.
So, as an example of behavior, running this new command: "swift install
danger/danger-swift" would:
- use the danger/danger-swift a shortcut for GitHub, and clone that repo
into a temporary folder
- parse the Package.swift
<https://github.com/danger/danger-swift/blob/master/Package.swift> then
let the user know they are going to install the CLI executable danger-swift
- run swift build in release mode
- install the executable into a folder in the users default path
This greatly reduces the friction to making more tools, and reduces the
number of dependencies for users to being the Xcode CLT which basically
everyone has out of the box.
I'm willing to take a stab at an implementation if this has approval of
Anders/Daniel.