Distribution through Cocoapods

[nmccann]

Hi,

I've been using SwiftLint for a few days now but found a few problems with how it is installed. A few of the problems (from my perspective):

• Requires action from new developers (either brew install or manually installing package)
• Difficult to specify a version that should be used
• Installed globally, which isn't good for shared environments like self-hosted CI (Bamboo). Particularly if you don't have permissions to do such an installation.

I have two suggestions:

• Provide a zipped copy of the binary and framework along with the package, source etc. that is currently included in each release.
• Provide a pod spec that would download the binary, similar to what is used by R.swift

Users who aren't interested in using Cocoapods could just directly download the zipped binary for the version they want.

I've got this working with a podspec in a private repo and a zipped binary/framework that I manually generated using make prefix-install. Having to do all of that manually isn't ideal though because it makes it harder to maintain. And I feel like other people could benefit from this functionality.

I think this would also partially solve #302

Please let me know if there are any issues/concerns with this approach. If there aren't any, I could try to make a PR that handles automatic creation of the zipped binary during the release process.

Thanks,
Noah

[jpsim]

Requires action from new developers (either brew install or manually installing package)
Difficult to specify a version that should be used
Installed globally, which isn't good for shared environments like self-hosted CI (Bamboo). Particularly if you don't have permissions to do such an installation.

All of these can be addressed for your use case (and #302) by bundling a pre-built version of SwiftLint with your project, similar to what Jazzy does with SourceKitten.

If you keep this directory structure, swiftlint will always link the framework in ../Frameworks:

├── Frameworks
│   └── SwiftLintFramework.framework
└── bin
    └── swiftlint

Provide a zipped copy of the binary and framework along with the package, source etc. that is currently included in each release.
Provide a pod spec that would download the binary, similar to what is used by R.swift

I have a hard time seeing us adding a third or fourth installation method for SwiftLint (the existing two being brew and .pkg).

A Podspec might make sense if anyone wants to use SwiftLintFramework in a CocoaPods project, however, so I'd merge a PR adding that.

[nmccann]

The downside I see with the Jazzy approach is that it involves committing a potentially large binary and framework in the repo. It also makes it more difficult to update, or to know when it should be updated. It becomes one more thing to check, in addition to things like pod outdated or bundle outdated that developers may already be doing.

[jpsim]

I'm sorry, this is just not something I want to support.

The downside I see with the Jazzy approach is that it involves committing a potentially large binary and framework in the repo. It also makes it more difficult to update, or to know when it should be updated. It becomes one more thing to check, in addition to things like pod outdated or bundle outdated that developers may already be doing.

You could make a simple Xcode build phase script for your project that downloads a zip of the Frameworks & bin directory structure mentioned above to a git ignored .swiftlint directory in your project's root.

[nmccann]

That's understandable, thank you for your time.

[samskiter]

+1 for this if you did reconsider. We're going to start distributing swiftgen the same as we have issues setting up and keeping the CI machines up to date (setting up homebrew non-interactively is basically impossible).

[jpsim]

@samskiter making a pod for SwiftLintFramework is definitely doable, so I've reopened this issue.

Making the swiftlint CLI executable would be a bit more difficult.

[marcelofabri]

@jpsim Couldn't we just publish the portable binary zip on releases and create a podspec? See #221 (comment)

[jpsim]

I might be missing something, but the portable zip thing was done really strangely, and should be entirely unnecessary. The resulting products from make installables should already be "portable".

And wouldn't it be preferable to use a from-source SwiftLintFramework podspec rather than binaries?

[samskiter]

What's the framework for? We just need the CLI. Maybe you need one podspec for the framework and one for the simple. Binaries (how protobuf/grpc seems to be set up)

…

On Fri, 2 Dec 2016, 17:52 JP Simard, ***@***.***> wrote: I might be missing something, but the portable zip thing was done really strangely, and should be entirely unnecessary. The resulting products from make installables should already be "portable". And wouldn't it be preferable to use a from-source SwiftLintFramework podspec rather than binaries? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#390 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNnW7C0Z9uHpEb6_w1Kp7W81FDJ3ZfDks5rEFrwgaJpZM4HIs4n> .

[jpsim]

How many CLI executables have you installed with CocoaPods before? Why would I add a fifth way to install the SwiftLint CLI using a tool that isn't designed for that at all?

[samskiter]

We've done it with swiftgen and protobuf/grpc. Fair enough though, I might use your binary .pkg and check that in.

…

On Sat, 3 Dec 2016, 02:54 JP Simard, ***@***.***> wrote: How many CLI executables have you installed with CocoaPods before? Why would I add a fifth way to install the SwiftLint CLI using a tool that isn't designed for that at all? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#390 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNnW2zRFEUt5aRwEGmUYLm2OZ22fW_bks5rENnigaJpZM4HIs4n> .

[marcelofabri]

The main advantage IMO of distributing the binary with CocoaPods is that homebrew doesn't have a way to enforce a certain version. Checking in the binary is an option, but I'd find it much easier to use CocoaPods as SwiftGen does.

[samskiter]

Yea that's the same advantage I like - an actual specified version. Plus automating homebrew on ci machines is a pain - you can't install it non-interactively I think

…

On Sat, 3 Dec 2016, 12:06 Marcelo Fabri, ***@***.***> wrote: The main advantage IMO of distributing the binary with CocoaPods is that homebrew doesn't have a way to enforce a certain version. Checking in the binary is an option, but I'd find it much easier to use CocoaPods as SwiftGen does. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#390 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNnW2Ff7yNOWUdCoGeTSG7SkgPTqu-Eks5rEVtDgaJpZM4HIs4n> .

[jpsim]

Hopefully #936 addresses this.