Adds KFCocoaPodsPlugin

[ricobeck]

This plugin only supports Xcode 5 but i found no policy how you handle this.

[supermarin]

@ricobeck awesome!

@jurre AFAIK from our last call, you guys agreed on keeping them under the same repo.
There's one thing that I'd fancy over having an xcode_version key for each plugin, it's rather having plugins_xcode4 and plugins_xcode5 parent nodes in JSON.

What are your thoughts on that?

[jurre]

Yeah that could work

[ricobeck]

One question that arises from the JSON structure: how are you going to handle the compatibility between different Versions of Xcode 5 for future releases? The new UUID checking will prevent plugins to work with newer versions.

[jurre]

Yeah we've been thinking about it a lot but we don't really see a good solution for that issue, very open to suggestions though!

[ricobeck]

One solution could be that the JSON file in the packages repo is only a bare file. When a pull request is merged a script (travis post install hook e.g.) parses the newly added xcodeproj file to find the Info.plist and checks the entries for XC4Compatible, XC5Compatible, and DVTPlugInCompatibilityUUIDs. This values can be added to the actual file loaded by the plugin. The plugin could check for them and filter the displayed list.

I admit that this is very complex.

[jurre]

That's a good suggestion, but it doesn't solve the case where plugins that are already installed don't support the current (newly updated) xcode version yet, which is our biggest concern.

[jurre]

If you don't mind I'd like to hold off merging this until we at least have the xcode versioning in master, @mneorr @kattrali what do you think?

[ricobeck]

I think the bigger problem is that also Alcatraz itself has to be updated after a Xcode version is released to be runnable again. I remember some Mail.app plugins dealing with the same (there the UUIDs have been there for a long time) by installing a helper modifying the plist. Ugly but i can't think of another solution.

To get back to the point: there is no problem for me to wait until the versioning issue is solved.

[jurre]

Yes, that's the biggest concern indeed. Modifying the plist kind of defeats the purpose of having the UUIDs in place (to not crash Xcode when a plugin doesn't work on a new Xcode version) but it is one of the options indeed. Appreciate your feedback btw!

[jurre]

Hi @ricobeck, trying to merge this but I'm getting the following error when trying to install:

PhaseScriptExecution Check\ Pods\ Manifest.lock build/KFCocoaPodsPlugin.build/Release/KFCocoaPodsPlugin.build/Script-C90012E6A43940B78D0347BA.sh
    cd "/Users/jurre/Library/Application Support/Alcatraz/Plug-ins/KFCocoaPodsPlugin"
    /bin/sh -c \"/Users/jurre/Library/Application\ Support/Alcatraz/Plug-ins/KFCocoaPodsPlugin/build/KFCocoaPodsPlugin.build/Release/KFCocoaPodsPlugin.build/Script-C90012E6A43940B78D0347BA.sh\"
diff: /../Podfile.lock: No such file or directory
diff: /Manifest.lock: No such file or directory
error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

** BUILD FAILED **


The following build commands failed:
    PhaseScriptExecution Check\ Pods\ Manifest.lock build/KFCocoaPodsPlugin.build/Release/KFCocoaPodsPlugin.build/Script-C90012E6A43940B78D0347BA.sh
(1 failure)

[ricobeck]

I managed it to track the cocoapods lockfile – this caused the out of sync message. I removed it, could you please try it again?

[jurre]

Still getting that error..

Usually having an (up to date) .lock file in your repo is preferred to make sure that every developer has the same exact versions of your pods.

from their docs:

Thanks to the Podfile.lock every machine which runs pod install on the hypothetical project will use RestKit 0.10.3 even if a newer version is available. CocoaPods will honour this version unless the dependency is updated on the Podfile or pod update is called. In this way CocoaPods avoids headaches caused by unexpected changes to dependencies.

[ricobeck]

Do you use the project or the workspace file?

[jurre]

We use the project file..

Adding workspace support shouldn't be too hard, I'm just thinking about a few things we'll have to consider

• How do we choose between the project and workspace files? We could always prefer the workspace if it's available, do you think that makes sense? We could also add an optional key to the package.json because:
• When installing workspaces we also need to specify a scheme, how do we get the scheme?

[ricobeck]

As there is no reliable mechanism for detecting the correct scheme i think it would be the best idea to add 'scheme' for project- and 'workspace_scheme' for workspace files.

• It is easily lint-able (only one key is allowed)
• covers also the case when you have multiple schemes in your project file
• allows distinction between projects and workspaces

[supermarin]

Just a note - i'm not sure if we should add cocoa pods support, since we could easily end up in a hell.
There's just so many failure points, and Xcodebuild does a pretty bad job with workspaces, has random failures etc.

I'd be more inclined towards adding a binary support, so developers build plugins themselves and we distribute .xcplugins

[ricobeck]

From my point of view (the contributor) it's better to have a binary option. I can release a plugin version and host it somewhere. I can even track the number of installations via my web server's access.log. No problems when i break my repo.
Downside: a problem occurs when i remove my hosted file.

[jurre]

Preferably people would use github releases right?

[supermarin]

This brings up a whole new level of thoughts,. ideally, we'd have a similar ecosystem like ruby gems.
We'd host immutable binaries, so if anything happens to the repo, the packages are still available.

[jurre]

Would you prefer to provide hosting like rubygems does or let plugin maintainers host them like homebrew does?

[supermarin]

@jurre initially was planning on our own hosting.

benefits:

• plugin state is immutable once submitted
• deleted plugin from owner still stays alive in our system

downsides:

• we need a sponsor if we don't want to pay $ x,xxx monthly
• lots of infrastructure to maintain on ourselves

After some time, my thoughts would be - maybe create a good CLI for developers and encourage proper tagging => Github releases for downloads.

[jurre]

@supermarin food for thought..

BTW I think there's currently a version of KFCocoaPods in the repo and we need to remove it since it can't be installed

[supermarin]

@jurre yeah we should remove it until it works.
I've posted a comment here: ricobeck/KFCocoaPodsPlugin#26

[guillaumealgis]

Sorry, same as #135 and #146. In order to cleanup the PRs, I'll close since this requires binary distribution.

Feel free to ping if anything changed on your side and we'll reopen 👍