Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CocoaPods downloads max out five GitHub server CPUs

github.com

Post reply on HN
Print view View original

31–40 of 320 posts

Re: CocoaPods downloads max out five GitHub server CPUs

#31

Post by superuser2 »

pjc50 wrote: post #14

This reply: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm... "Not having to develop a system that somehow syncs required data at all means we get to spend more time on the work that matters more to us, in this case. (i.e. funding of dev hours)" In other words, using github as a free unlimited CDN lets them be as inefficient as they like. Such as having 16k entries in a directory ( https://github.com/Co…

Perhaps because Cocoapods is not an OS package manager or anything close to it. It installs libraries within the context of an XCode project, regardless of the host system or what is installed for other projects.

Re: CocoaPods downloads max out five GitHub server CPUs

#32

Post by emeraldd »

sdegutis wrote: post #5

I love how this was like the perfect storm of things that could go wrong, and how it seems like mhagger is just amazed more than anything else.

It's nice to see that they post a technical analysis of the problems with some very reasonable sounding potential fixes rather than just killing the repo.

Re: CocoaPods downloads max out five GitHub server CPUs

#33

Post by wpeterson »

It's totally reasonable to host your code on github and to build a package manager that loads the content of a package from it's github repo.

What seems insane is to use a single github repo as the universal directory of packages and their versions driving your package manager.

There's a reason rubygems has their own servers and web services to support this use case for the central library registry, even if the source for gems are all individually projects hosted on github.

Re: CocoaPods downloads max out five GitHub server CPUs

#35

Post by revelation »

zeveb wrote: post #12
revelation wrote: post #7

Earlier quoted context omitted.

Hardly. Do they hit edge cases? Yes! Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! The response from mhagger is unnecessarily apologetic, and I predict we'll see an official update from GitHub on this soon.

> Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! I don't know about that. Both oh-my-zsh[1] and emacs prelude[2] use git repos as their code distribution mechanisms, and that works really well. I think the real issues here are exactly what is called out in the issue: poor usage of git, and poor directory layout. [1] https://github.com/robbyrussell/oh-my-zsh [2] https://github.c…

They are using GitHub for their intended purpose, hosting their code. That is perfectly fine.

What is not perfectly fine is using GitHub as your package host, CocoaPods/Specs is the equivalent of Debians APT using one big GitHub repo to host all their packages. It has 92567 commits and 6872 contributors.

Re: CocoaPods downloads max out five GitHub server CPUs

#37

Post by revelation »

joshribakoff wrote: post #22
revelation wrote: post #7

Earlier quoted context omitted.

Hardly. Do they hit edge cases? Yes! Is using GitHub for your CDN a dick move and going to cause problems, regardless? Yes! The response from mhagger is unnecessarily apologetic, and I predict we'll see an official update from GitHub on this soon.

Using GitHub for a CDN would be hotlinking to a .js file from your production website, not whats happening here. Other package managers do the same, for example "bower" will clone from github, it just does normal clones.

I think you're missing my distinction here. Yes, bower will clone from GitHub, but of course only the packages you actually use; in the same sense that Go can import source from GitHub repos. These repos are storing code and using GitHub as intended.

But CocoaPods/Specs is the equivalent of someone collecting all possible packages you could ever use in Bower in one big GitHub repo.

Re: CocoaPods downloads max out five GitHub server CPUs

#39

Post by wpeterson »

Negative1 wrote: post #34

When he says approaches similar to 'other packaging systems', which ones is he referring to? I can see why this is a bad approach but am unfamiliar with what would be considered a better practice (outside of just hosting a .tar on CloudFront).

RubyGems.org has their own web server and web services for publishing library versions and to allow the clients to fetch libraries and query the universal registry.

Re: CocoaPods downloads max out five GitHub server CPUs

#40

Post by barkingcat »

arrakeen wrote: post #20
dankohn1 wrote: post #9

Earlier quoted context omitted.

Yes, it's a hugely positive advertisement for the essential role that Github plays in the open source community. Also impressive is the followup message from a Github API developer (and Homebrew maintainer) offering access to a beta API that Homebrew is working with to reduce load. https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...

taking a look at homebrew's implementation of this new API feature, i fail to see how it would dramatically reduce fetches for their (homebrew's) use case. from what i understand, it will only be called when the user manually invokes `brew update`. how often are users calling this command over and over? that being said, i do believe it could help cocoapod's use case since the fetches are done automatically (as i unde…

brew update is being called over and over again in most use cases - if only to check for example, if the latest openssl release patching a critical exploit is out yet. (of course on the mac openssl is packaged with the system, but if you are using the brew version, or are compiling other software against openssl from brew, you'll need to check for updates diligently)

It is also being used in scripts, etc. Since from the user's point of view it's a no-op if there are no updates, there is no reason not to do it on a schedule.

Post reply on HN