Carthage support branch is 13 behind master

[dennispost]

Is there a reason why Carthage support is not in master?

The 1Password App Extension API is available via Carthage as well. Simply add github "AgileBits/onepassword-extension" "add-framework-support" to your Cartfile, then run carthage update and add it to your project.

[chrismanderson]

This has fallen behind again. Any way we can get Carthage support on the normal master build?

[gks]

@chrismanderson I've gone ahead and released version 1.8.5 of the app extension today. With that release I've also updated the add-framework-support branch to match master.

[chrismanderson]

Thanks for updating! But, can we get Carthage support into master? Seems like a never-ending hassle to keep branches in sync (plus it feels odd to have to separate 'production' branches of a library).

[gks]

@chrismanderson You're welcome, sorry it took so long, but I don't anticipate this being an issue going forward now.

I don't see us moving carthage support into master I'm afraid. Maybe one day we'll have a single framework solution that everyone uses, at which point we won't have to deal with the mess of different framework options like we have to do now.

[chrismanderson]

I guess I'm confused, and would love clarification, why not though? :stuck_out_tongue_winking_eye:

Every other open source iOS library that I've encountered has both Cocoapod and Carthage support in the same branch. Can you all not have them in the same branch because you support older versions of iOS? Or some other reason? I'd love to know the reason for not merging if nothing else for my own understanding. Thanks!

[gks]

@chrismanderson More a fundamental philosophy of how we as a company do things, or don't in this case. We use as little outside code as we humanly can in 1Password, especially on Mac and iOS (where I work primarily). So none of our Mac and iOS teams use these package management/framework tools. If we don't use them it's quite easy for an issue surrounding those to be missed. So along the lines of dog fooding it, we don't with the Cocoapods and Carthage side of things.

[chrismanderson]

That's all well and good, and I'm sorry to be a broken record I swear I'm not trying to be annoying, but why does not using Carthage and Cocoapods internally mean that you can't have the framework on the master branch? Ala Cocoapods support doesn't require a different As far as I can tell, the only difference is that the Carthage branch contains an Xcode project file whereas master doesn't, which then can't you all just put the project file on master then boom done?

[gks]

@chrismanderson You're not being annoying at all.

If we merge it to master it means we are sort of inclined to provide support for it. And removing it is incredibly difficult as a result. I think in an ideal world we'd rather have the community maintain that side of things and they'd be responsible for helping people who had build related issues, or setup issues with their projects. At least those issues directly related to the package manager being used.

If we don't use something, we're not familiar with it, providing support for it (the technical kind) becomes more difficult and time consuming. It can be beneficial to be really opinionated about these types of things.

Of course we want to help people add support for the App Extension in their apps. So these framework options exist.

The 1Password App Extension is incredibly simple to setup. It can be easily copied directly into a project, submoduled, or vendored and updated easily. I struggle to understand why a developer would want to use Carthage or Cocoapods for something like our project. It feels like a great deal of overhead that isn't at all necessary. Clearly people find it valuable though so we have them kicking around.

It took me 30 minutes today just to update the Cocoapod for the 1.8.5 release today because of all kinds of fun dependencies to get Cocoapods running properly. Releasing the mainline release took all of 5 minutes. Just my experience, almost none of which has been positive :)

[chrismanderson]

FWIW, I never integrate any third party library in my apps unless they are through Cocoapods or Carthage. Part of the reason is convinience for sure, I can look at a Pod/Cartfile and see a easy to parse list of my app's dependencies. I remember the days pre-Cocoapods of dealing with manual integrations, dragging and dropping, weird build settings, and all of that which Carthage/Cocoapods helps to solve. And as for your library, while it's one of the simplest for sure, it's still a third-party library so I want to, as much as possible, treat it like I would every other library in my app.

(And yes, I agree about Cocoapods being complicated, it's been incredibly helpful to me over the years but does have warts for sure, which is why I'm switching to Carthage which is far simpler and requires less mucking about Xcode.)

And my last argument, then I'll leave you to keep making 1Password awesome, is if you don't want to offer for Cocoapods and Carthage (which is your preogative) then Cocoapods shouldn't be on the master branch either. Either have both of them be buildable from master, or neither.

[gks]

We'd agree with you on that as well. We've made no decisions to remove or adopt support for either. For the time being I anticipate things will remain the way they are. Personally I'm hoping that like the VHS and Beta we see a winner and that'll make things easier. The split here isn't making things better.

Going forward, now that I have a process in place, the add-framework-support branch should remain up to date with master. There were some rough spots because change in personnel handling this project and I had a fair bit of things to work into my process. That's on me and no one else. But going forward it shouldn't be as big of a deal. So don't expect anything to change here but also you shouldn't see that branch behind as it was in the past.