Closed nmccann closed 7 years ago
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.
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.
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
orbundle 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.
That's understandable, thank you for your time.
+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).
@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.
@jpsim Couldn't we just publish the portable binary zip on releases and create a podspec? See https://github.com/realm/SwiftLint/issues/221#issuecomment-257131481
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?
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, notifications@github.com 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 https://github.com/realm/SwiftLint/issues/390#issuecomment-264517416, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNnW7C0Z9uHpEb6_w1Kp7W81FDJ3ZfDks5rEFrwgaJpZM4HIs4n .
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?
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, notifications@github.com 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 https://github.com/realm/SwiftLint/issues/390#issuecomment-264611274, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNnW2zRFEUt5aRwEGmUYLm2OZ22fW_bks5rENnigaJpZM4HIs4n .
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.
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, notifications@github.com 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 https://github.com/realm/SwiftLint/issues/390#issuecomment-264635407, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNnW2Ff7yNOWUdCoGeTSG7SkgPTqu-Eks5rEVtDgaJpZM4HIs4n .
Hopefully #936 addresses this.
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):
brew install
or manually installing package)I have two suggestions:
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