Cocoapods: Distribute via Homebrew

[keith]

It seems like we should start distributing CocoaPods via homebrew. Distributing via RubyGems is really just an implementation detail. I'm not suggesting we try to have updates reviewed each time we want to release, instead I'm suggesting we create our own homebrew tap and distribute our own formula there. An example of how this can be done, and scripted, for a Ruby based project can be found here.

This would also help us with dealing with issues around Ruby installations, system Ruby and sudo or not.

[segiddins]

@Keithbsmiley I also like that since I change global rubies (relatively) frequently, but I've only once nuked my homebrew setup

[keith]

Another great reason for sure. Didn't even think of that!

[orta]

I think the long term prospect is a form of CocoaPods.app like tokaido.

Relying on a different installer just brings with it its own problems around pre-requisitve tools and installers, shipping a binary hopefully would negate most of this.

[keith]

I don't think it's much to ask for a developer who is using the command line for something to have Homebrew installed. But regardless, like what that application does, we could have multiple install paths for user preference in this case. Personally I wouldn't want to use a binary for the installation method like that.

[orta]

Rubygems comes pre-installed though, we're now asking for a minimum of three commands ( or a script ) to install CocoaPods.

To some extent we're already asking a lot for using a command line interface, there's a lot of people waiting on a magical cocoapods gui. Jumping from Xcode to Terminal isn't exactly intuitive for non-terminal people.

[marklarr]

It's actually nice to be able to put cocoapods into a Gemfile and force people to all be on the same version (preferably the latest) IMO. Once people start trying to put cocoapods on their system ruby (or something without a version manager like homebrew) you can run into all sort of annoyances like the Podfile.lock getting overwritten again and again with different versions of cocoapods

[keith]

That's assuming users actually run brew update && brew upgrade often. Which either way, we want them to do.

[segiddins]

The nice thing about keeping it with ruby gems is that we have the dependency resolution for our runtime deps

[keith]

I'm not saying we should drop RubyGems internally. You'd develop the same was as you do currently. The only difference would be the distribution package would be bundled with the runtime dependencies and released, rather than the users downloading them.

[marklarr]

But if a runtime dependency has a fuzzy selector, ie s.add_runtime_dependency 'xcodeproj', '~> 0.17.0', this would mean nothing if distributing via homebrew. When installing through rubygems and using bundler, you'd automatically get any patch updates (ie, `0.17.1), whereas with homebrew we'd need to package up a new release.

Not the end of the world but seems like a step back

[keith]

I think that leads to a more stable release from us. We've seen a lot of issues lately with conflicting versions of ActiveSupport that we wouldn't have to deal with otherwise.

[marklarr]

Interesting. As long as gem dependencies are following the guidelines of semantic versioning, I don't see why automatically accepting patch updates should break anything.

[keith]

They weren't breaking semantic versioning guidelines it was just conflicting because sometimes ruby dependency management is hard haha.

[marklarr]

lol. Well what if cocoapods was distributed via homebrew and RubyGems? This way homebrew could replace the gem install cocoapods system ruby install method, but the Gemfile method would still be available? Because installing on system ruby and installing with bundler are two pretty different use cases.

[keith]

That's definitely fine with me. I think that the recommended path in that case should be to install with Homebrew. Then users who feel otherwise could use the gem method as needed.

[kylef]

This adds many steps to installing CocoaPods, we go from this:

$ [sudo] gem install cocoapods

To this:

$ ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
$ brew tap CocoaPods/formulae
$ brew install cocoapods

There would need to be instructions stating that some of these steps are not necessary if you have Homebrew.

---

This also means that we go from being able to install CocoaPods without admin privileges (corporate environment) with RubyGems, to requiring administrator privileges to install CocoaPods (homebrew).

With the reasons stated above, this is a really inelegant solution and I don't think we should consider it.

[keith]

Seems like the votes are against this. Closing

[gfontenot]

Just going to throw in a vote for Homebrew. Using a language's dependency management system as a system package manager is Bad™. Using RubyGems to install CocoaPods is as crazy as using CocoaPods to install RubyGems. The language that a library is written in shouldn't leak out through its install process.

In my opinion, the best long-term solution would be:

1. Main distribution is done through Homebrew (or something better if it magically bursts into existence)
2. "Easy" distribution through some sort of self-contained installer (see #400)
3. Development distribution (for testing/people that feel like screwing around with pre-release dependency management systems) on RubyGems (_maybe_)

I could personally do without the last one. It seems to me like it would be trivial for people working on dev versions to set up their own aliases that point to the actual source and run it directly.

[marklarr]

Using RubyGems to install CocoaPods is as crazy as using CocoaPods to install RubyGems.

I see where you're trying to go with that, but it's really not a fair comparison. The major difference you're overlooking is that RubyGems allows system-wide gems, not to mention bin executables.

[irace]

FWIW (probably very little), I've _never_ used Homebrew. I've also never written Ruby and had never installed a gem prior to CocoaPods, but haven't found the reliance on gem install to be a hindrance whatsoever.

That said, a native CocoaPods.app (ala Tokaido) sounds just splendid.

[keith]

I think in the case of developers who don't often use Homebrew or RubyGems the GUI installer will be the best solution.

[neonichu]

I think we all agree on that, that's why #400 is still open and this is not :)

[gfontenot]

@neonichu Answering your question from twitter, if this were installed via homebrew, you would (and should) _force_ it to rely on system ruby. Not sure what you mean by "essentially the same" though.

[gfontenot]

@marklarr I don't think it's an unfair comparison at all. RubyGems is a dependency management tool for Ruby, CocoaPods is a dependency management tool for Objective-C. But to take my analogy further, would you want to install npm via RubyGems if it were written in Ruby? How about installing CocoaPods via npm, if it were written in Node. My point is less about the ability to install executables, and more about the fact that the choice of language shouldn't impact the method of distribution, _unless_ the tool directly relates to the language. It makes sense for Xcodeproj to be distributed via RubyGems, because it's intended to be used in Ruby development. But given that CocoaPods is a lot of times the _only_ thing Cocoa developers need to use Ruby for, it seems like a poor choice.

[marklarr]

I'd argue that bundler is a dependency management tool, RubyGems is just a package distribution tool. Cocoapods is not entirely analogous to RubyGems. It's more like RubyGems + bundler, without system ruby.

[neonichu]

@gfontenot I was just wondering if it was another solution with the same outcome or achieving something different entirely.

As it is basically just keeping the user from invoking the "wrong" version of the gem command, I still think #400 is the only solution that really makes sense to me. Once it exists (1.0 timeframe), people can make their own homebrew formula based on it.

[gfontenot]

@marklarr Fair point. I blur Bundler and RubyGems in my brain because I'm dumb.

@neonichu I suppose a formula based on #400 makes sense, but (theoretically, I obviously have no idea what Alloy is actually planning on) it could run into problems with the bundled versions of git, mercurial, svn, etc. Assuming you could _only_ install the pod executable, it seems like that would be a reasonable compromise.

[marklarr]

@gfontenot don't be so hard on yourself, it's an easy mistake to make :)

[keith]

For anyone who actually wants this:

brew tap Keithbsmiley/formulae && brew install cocoapods

[neonichu]

@Keithbsmiley 💗

[alloy]

@Keithbsmiley Awesome. So from what I gather, this uses system Ruby, right?

[keith]

Yep it uses system ruby without loading other gems. It is therefore unaffected by users ruby environments. I haven't tried but this might break plugins.--
Keith Smiley

On Thu, Oct 2, 2014 at 1:46 AM, Eloy Durán [email protected]
wrote:

@Keithbsmiley Awesome. So from what I gather, this uses system Ruby, right?

Reply to this email directly or view it on GitHub:
https://github.com/CocoaPods/CocoaPods/issues/2238#issuecomment-57599582

[netbe]

@Keithbsmiley I like this!

[orta]

https://github.com/cocoapods/cocoapods.app may likely negate the need for this too.

[keith]

@orta I definitely disagree with that. Installing a CLI through a GUI is the only thing I would like to do less than installing it through gem

[marklarr]

I'm with @Keithbsmiley on that one. I already hate Xcode and Crashlytics -- I don't want to hate CocoaPods too.

[keith]

I'm also not saying the GUI doesn't make sense. As it has been talked about before, that could be a nice installer for people who don't typically use the command line.

[orta]

:) fair enough gentlemen

[marklarr]

Would the app just be an alternative installation method that simplifies the installation of the Gem?

[orta]

It contains the entire dependency hierarchy for CocoaPods ( & git & hg & svn etc ) inside itself, ala Xcode. So that a sparkle app update will update all internals. I didn't entirely mean negate the need for the home-brew, more that the contents of this itself could be what is sent.

[segiddins]

The app will also (eventually) have a GUI

-Samuel E. Giddins

On Nov 18, 2014, at 12:46 PM, Orta [email protected] wrote:

It contains the entire dependency hierarchy for CocoaPods ( & git & hg & svn etc ) inside itself, ala Xcode. So that a sparkle app update will update all internals. I didn't entirely mean negate the need for the home-brew, more that the contents of this itself could be what is sent.

—
Reply to this email directly or view it on GitHub.

[keith]

Since homebrew obviously supports depending on the mentioned tools I would rather use their mechanisms for that than shipping those bundled versions.

[netbe]

Is maintaining the three ways (rubygems, homebrew, .app) to distribute cocoapods an issue and so there's a need to drop one?

[keith]

The homebrew distribution is not maintained by CocoaPods directly. It lives on my fork which is rebased on each release. Maintaining it also doesn't require much work since the distribution is all done automatically by running the release script.

[houmie]

+1 home brew support

[MikeMcQuaid]

@Keithbsmiley Homebrew maintainer here. I'd like to work with you on getting this part of Homebrew core. Let me know the best place to discuss this and let's try and get there.

I've had people ask us why this isn't already part of Homebrew core and I'd like to provide this option for them to install it, even if it's not officially sanctioned.

[keith]

@mikemcquaid gladly. My formula works now, I can go ahead and submit a PR for the current version?

[MikeMcQuaid]

@Keithbsmiley The only problem I see with your formula as-is is it's not using any upstream source files. Can we instead try and work on a formula that generates the same output as your formula from the original sources somehow? Thanks!

[MikeMcQuaid]

(and then we can provide a "binary" package if that's a slow process)

[keith]

Meaning that the formula would pull from this repo instead of my fork?

[MikeMcQuaid]

Yup.

[keith]

I've submitted a PR to merge in my simple setup code. Having this officially supported would make everything much easier https://github.com/CocoaPods/CocoaPods/pull/3010

[syxchina]

@keith
brew tap Keithbsmiley/formulae && brew install cocoapods
thanks

[aguynamedben]

+1, homebrew is the de facto standard for devs installing dependencies. Knowledge of Ruby's package management should not be necessary. The current instructions for CocoaPods installation also advise sudo gem install, which is you ask people in the Ruby community is not great...

[keith]

My GitHub username changed. It seems like GitHub is redirecting repo URLs for the time being but I recommend that in the future you do:

brew tap keith/formulae && brew install cocoapods

Of course this wouldn't be an issue if this was in the official repo :trollface:

[MikeMcQuaid]

brew install keith/formulae/cocoapods will do this in a single command.

[heypaulmcgrath]

Thanks, Mike!

[hfossli]

Come on! Really? Cocoapods is for people who make apps.. [sudo] gem install cocoapods have at times been troublesome to me. And I would hesitate from using a GUI for doing something which isn't as fully transparent as $ brew install cocoapods. Are we moving away from using $ pod install from terminal as well? I really don't get this.

I definitely would love to use brew rather than an app or gem.

[neonichu]

There's a cask for the app, which still comes with the pod binstub, it is just a distribution method:

$ brew cask install cocoapods

[alloy]

@hfossli The app is foremost a container for the CLI tools, it contains all dependencies, up-to-date versions thereof (Ruby, OpenSSL, etc), and requires nothing else to be installed (up-to-date gem, brew, or properly configured CLI build chain). After you’ve installed it, you will normally still use pod install from the Terminal.

[MikeMcQuaid]

There's a cask for the app, which still comes with the pod binstub, it is just a distribution method:

@neonichu I'd recommend people use brew install Caskroom/cask/cocoapods instead which will auto-install brew cask if people don't already have it installed (or know/care what it is)

[neonichu]

@mikemcquaid ah great, didn't know about that, thanks :+1:

[neonichu]

BTW, maybe it makes sense to mention the cask installation method on the website, along with gem install?

[keith]

Obviously we know my position on this, but making a GUI to be a container for the dependencies seems like reinventing the wheel.

Regardless my homebrew tap is still up to date for anyone who wants to use it:

brew install keith/formulae/cocoapods

[neonichu]

@keith One can easily also argue the reverse :). App bundles, not homebrew formulas, are the prevalent distribution method on OS X after all.

[keith]

Not for command line tools.

[hfossli]

I second that

[hfossli]

Why did i second that. No need to second facts 😀 I don't know of any / use any command line tool installed via GUI except those bundled with xcode.

[alloy]

I know of a whole lot of prebuilt command-line tools that come in installer packages. Those install in a single place and can easily ‘break’. Not so with the app, you can place it anywhere and it keeps working.

This is for the people that don’t want anything to do with installing any CLI toolchains etc, they just want it to work. Home-brew doesn’t help with that, as it is not pre-installed.

So now there’s two ways to install that we mention, on other side of the spectrum, that’s good. If you want your own option, that’s perfectly fine, but they don’t all need to be offered in the same place and overload the user who just wants the simple option.

[alloy]

This thread has become a large conflation of several issues, which isn’t really productive. To be clear, we’re not going to advertise homebrew as an installation option among the two we already have. Less options is better for first time users and the homebrew option requires you to first install homebrew, so it’s simply a more complicated route.

I’d also argue that people that want to install through homebrew would probably just check with brew search, no? I personally never go to a project’s website to see if they support homebrew, I just try it.

So to be clear, I’m not against having the option for homebrew users to be able to install through homebrew in the way that @keith imagined _at all_ and as such I think we should focus on just having it work _at all_.

@mikemcquaid I’m really confused as to why @keith’s formula is not in the core repo? This thread, to me, reads as “because there is a cask we won’t accept this formula in core, even though it annoys us”. Can you elaborate on what exactly is the reason that’s keeping you from accepting @keith’s formula?

[MikeMcQuaid]

@mikemcquaid I’m really confused as to why @keith’s formula is not in the core repo? This thread, to me, reads as “because there is a cask we won’t accept this formula in core, even though it annoys us”. Can you elaborate on what exactly is the reason that’s keeping you from accepting @keith’s formula?

The reason that's keeping it is that @keith's formula requires his forked version of CocoaPods rather than building from the main repo (https://github.com/keith/homebrew-formulae/blob/34d115e244a53ecf5e9126307c8ef0c12a135eb9/Formula/cocoapods.rb#L5). I would rather have a CocoaPods formula in Homebrew core but for that to happen CocoaPods needs to be willing to accept @keith's changes into the main repository. See the conversation in https://github.com/CocoaPods/CocoaPods/pull/3010.

I suspect I'm going to get criticised for Homebrew being inflexible here but I'd just like to point out it's extremely rare for Homebrew maintainers to be actively working with upstream projects to try and get them included in Homebrew, even more-so when it's a project they don't use. I think brew install cocoapods would be great for both projects which is why I've tried to work towards it but I'm getting pretty mixed-messages from CocoaPods land.

[alloy]

I would rather have a CocoaPods formula in Homebrew core but for that to happen CocoaPods needs to be willing to accept @keith's changes into the main repository. See the conversation in #3010.

So if I’m correct, the issue is that for the homebrew distribution method, a specialised tarball has to be crafted, which is what @keith’s script does?

(I did not understand up till now that there was more work required than just a formula.)

So, let’s say that @keith would be willing to maintain this, what is the technical reason for the build scripts to be inside the main repo?

I suspect I'm going to get criticised for Homebrew being inflexible here but I'd just like to point out it's extremely rare for Homebrew maintainers to be actively working with upstream projects to try and get them included in Homebrew, even more-so when it's a project they don't use.

I don’t know why you’d suspect that, it is much appreciated.

[MikeMcQuaid]

@alloy The short answer: the issue isn't the tarball necessarily but that the tarball is created and published manually by @keith and in his repo rather than anywhere official under the CocoaPods org and part of the official release process. Although @keith's work here has been great we in Homebrew-land don't like these type of things because e.g. if @keith is on vacation/hit by a bus and CocoaPods publish a new release then his fork won't be updated, his tarball won't be published and Homebrew has to explain to disappointed users why we don't have the latest CocoaPods. I'd be totally OK with something that lived outside the main repo as long as publishing it became not just on @keith and part of the official release process (e.g. it gets published when you publish the new gem).

[neonichu]

@mikemcquaid I probably partially caused the confusion about this with this comment which was missing a bunch of context from private discussions, apologies for that.

Just to recap:

• We didn't really want to have all the additional scripts in the main CP repo, that was the reason for not merging #3010
• It was our understanding that if it's not in the main repo, the formula wouldn't be officially accepted, that's why we opted for the cask

Hope that clears the situation up :)

[alloy]

@mikemcquaid I see. This makes a lot of sense, thanks for that clarification.

I'd be totally OK with something that lived outside the main repo as long as publishing it became not just on @keith and part of the official release process (e.g. it gets published when you publish the new gem).

Gotcha 👌

@keith Would you be up for maintaining the scripts inside the Rainforest release process?

[MikeMcQuaid]

@neonichu Really appreciate the apology, thanks :heart:. No worries about the confusion; I caused a fair bit myself too! For me/us it's not so much about the repo as the organisation and it being done by a team rather than an individual. Hope that clears things up a bit!

[alloy]

Just a quick in-between recap, so that we ensure we’re all still on the same page:

• It looks like we’re on track to making CocoaPods available in homebrew core for each release, which is great news for homebrew users :+1: :100:
• (As discussed in private) I’m unconvinced the cask distribution method makes much sense. It looks like more effort for us to maintain it than for people to just download the archive and place the app wherever they prefer, especially as it also does not help in updating etc, we still do that through Sparkle.
• Us pushing releases to homebrew does _not_ necessarily mean we’ll advertise it as an installation option on the installation page, which is supposed to be as simple as possible. The two are not mutually exclusive. Some discussion is here https://github.com/CocoaPods/cocoapods.org/pull/187.

[keith]

I'd be happy to support this in the rainforest repo assuming I can get it set up there.

[patsplat]

+1 to everyone. nice pragmatic thread.

[her]

brew install cocoapods

I'm pretty confused here, after reading this entire thread it seemed like cocoa pods would be added to homebrew??

what kept cocoapods from doing this? Mike himself from homebrew even offered a hand!

[keith]

I haven't gotten to making this work in the rainforest infrastructure. I've continued using my homebrew tap in the meantime. Any help would be appreciated.

[segiddins]

@her we've never gotten a PR adding this functionality to rainforest. If you'd like to do that, we'd be happy to merge it, but as stated many many times in this thread, adding this functionality (vs maintaining it) is not a focus for the core team.

[her]

Thanks for the quick replies guys. so then for brew users:

brew install keith/formulae/cocoapods

should work @keith?

https://github.com/CocoaPods/Rainforest is where brew needs to be added then ?

@segiddins I understand :) thanks for replying to me. Though I do want to push and say, it would be _awesome_ functionality 🙃

[keith]

Yep that command works. And yes that's where support needs to be added.

[MikeMcQuaid]

I've shipped brew install cocoapods: https://github.com/Homebrew/homebrew-core/pull/507

[her]

This is fantastic 😍 great news 👏🏻

[orta]

This looks perfect to me 👍 - I'm happy closing this, we should look into updating that as a part of our deploy process. Great work @mikemcquaid - you're doing a kick-ass job at running home-brew,

[MikeMcQuaid]

Cheers @orta.

[orta]

Quick Q, just to make sure: could this conflict with the CocoaPods Mac App's brew cask?
As we have both brew cask install cocoapods and brew install cocoapods

[MikeMcQuaid]

@orta Yes, they may conflict if you install them both at once. We're working on addressing conflicts like this between the projects better and it may be a GSoC project.

[keith]

Thanks @mikemcquaid awesome stuff!

[mderazon]

Sorry for spamming everyone, but does anyone know if it's possible to install with --pre flag via homebrew ?
(Install beta versions)

Tried something like

$ brew install [email protected]

But it didn't find anything

[MikeMcQuaid]

@mderazon brew install --devel cocoapods

[ryanbooker]

This no longer appears to work… How does one acquire the --pre version now?

[brodybits]

/usr/local/bin/brew install cocoapods works for me (I use complete path to /usr/local/bin/brew since I also have a version of Homebrew installed in my home directory)

_P.S. I found a nice guide at: http://brewinstall.org/install-cocoapods-on-mac-with-brew/_

_P.S.S. I got rid of the extra homebrew installation, brew install cocoapods seems to do the trick now._

[ghost]

OH MY GOD I CAN'T BELIEVE COCOAPODS IS AVAILABLE VIA HOMEBREW

The sudo less install hurt so much. Soooooo much.

THANK YOU

Please make this more visible in your guides

[MentalGear]

Is there a particular reason install via homebrew is not described on the cocopods install page ?

[codemaestro]

Even cooler only a few months later. Both of these work:

1. $ brew install cocoapods

2. $ brew install --cask cocoapods

I tried 1. first and was told that "cocoapods was going to be treated like a formula". So I uninstalled it and reinstalled using 2.

After running brew info cocoapods and brew info --cask cocoapods (learning from https://stackoverflow.com/a/53809203), I found that the formula installed a more recent version than the cask. So I uninstalled the cask and reinstalled using 1.

However, being new to brew, I can't find any info as to why I would rather install as a cask or as a formula. Maybe when https://cocoapods.org/ is updated someone could explain the differences between a formula and a cask when both are available?