51–60 of 320 posts
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.
How so ? I bet the cocoapods team knew they were hammering Github with that gigantic repo. They just didn't care and expected Github to just give them more bandwidth, for free.
The CocoaPods developers seem to be missing the entire point of git: it's a _distributed_ revision control system.
Setup a post-recieve hook on Github to notify another server, that is setup with a basic installation of git, to pull from Github so as to mirror the master repo. Then, have your client program randomly choose one of these servers to pull from at the start of an operation. Simple load balancer to solve this problem.
Another reason I consider https://github.com/Carthage/Carthage a better solution of the dependency management problem.
And https://github.com/apple/swift-package-manager once it's ready, which is similar to Carthage in structure (decentralized!).
> We would like to provide a package index in the future, and are investigating possible solutions.
[1]: https://github.com/apple/swift-package-manager/blob/master/D...
I find it amusing how GitHub's contact[1] form has (probably a recent addition): > GitHub Support is unable to help with issues specific to CocoaPods/CocoaPods. --- [1]: https://github.com/contact
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.
No matter which way you slice it, what CocoaPods is doing is a bit daft, especially at their scale.
Earlier quoted context omitted.
It's very "sharing economy": someone else has a resource you can use for free, so why not take it? (Edit: )
Because abusing that resource makes sure you (or anyone else) won't be able to take it in the future. I thought that's pretty obvious?
Earlier quoted context omitted.
> 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.
The big differences seems to be in the way they do their thing: I'm reasonably sure homebrew just git clones then updates the local repository normally[0], it has "only" 2500 files in Library/Formula, and because of its different subject it is way less write-active, CocoaPod has 1k commits/week which look to be increasing pretty much constantly, homebrew is around 350 with ups and downs.
Also not sure it matters, but homebrew has lots of commits updating existing formula, cocoapod changes are almost solely addition (publishing a new version of a package adds a new spec and doesn't touch the old one)
[0] which is exactly the bread and butter of github
Earlier quoted context omitted.
It's very "sharing economy": someone else has a resource you can use for free, so why not take it? (Edit: )
Because abusing that resource makes sure you (or anyone else) won't be able to take it in the future. I thought that's pretty obvious?