[swift-build-dev] Support installing SwiftPM executables from remote repos

[Ankit Aggarwal]

Hi Orta,

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 at 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.
>
> --
> [A.]       Orta Therox
>
> w/ Artsy <http://artsy.net/>
> CocoaPods <http://cocoapods.org/> / CocoaDocs <http://cocoadocs.org/>
> @orta / orta.github.com
>
>
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170915/ddf392f5/attachment.html>