cocoapods / cocoapods-repo-shard

Shard a CocoaPods specs repository

CocoaPods: The Cocoa dependency manager

CocoaPods manages dependencies for your Xcode projects.

You specify the dependencies for your project in a simple text file: your Podfile. CocoaPods recursively resolves dependencies between libraries, fetches source code for all dependencies, and creates and maintains an Xcode workspace to build your project. The latest released Xcode versions and the prior version are supported.

Installing and updating CocoaPods is very easy. Don't miss the Installation guide and the Getting Started guide.

Project Goals

CocoaPods aims to improve the engagement with, and discoverability of, third party open-source Cocoa libraries. These project goals influence and drive the design of CocoaPods:

• Create and share libraries, and use them in your own projects, without creating extra work for library authors. Integrate non-CocoaPods libraries and hack on your own fork of any CocoaPods library with a simple transparent Podspec standard.
• Allow library authors to structure their libraries however they like.
• Save time for library authors by automating a lot of Xcode work not related to their libraries' functionality.
• Support any source management system. (Currently supported are git, svn, mercurial, bazaar, and various types of archives downloaded over HTTP.)
• Promote a culture of distributed collaboration on pods, but also provide features only possible with a centralised solution to foster a community.
• Build tools on top of the core Cocoa development system, including those typically deployed to other operating systems, such as web-services.
• Provide opinionated and automated integration, but make it completely optional. You may manually integrate your CocoaPods dependencies into your Xcode project as you see fit, with or without a workspace.
• Solve everyday problems for Cocoa and Xcode developers.

Sponsors

Lovingly sponsored by a collection of companies, see the footer of CocoaPods.org for an up-to-date list.

Collaborate

All CocoaPods development happens on GitHub. Contributions make for good karma and we welcome new contributors with joy. We take contributors seriously, and thus have a contributor code of conduct.

Links

Link	Description
CocoaPods.org	Homepage and search for Pods.
@CocoaPods	Follow CocoaPods on Twitter to stay up to date.
Blog	The CocoaPods blog.
Mailing List	Feel free to ask any kind of question.
Guides	Everything you want to know about CocoaPods.
Changelog	See the changes introduced in each CocoaPods version.
New Pods RSS	Don't miss any new Pods.
Code of Conduct	Find out the standards we hold ourselves to.

Projects

CocoaPods is composed of the following projects:

Status	Project	Description	Info
	CocoaPods	The CocoaPods command line tool.	guides
	CocoaPods Core	Support for working with specifications and podfiles.	docs
	CocoaPods Downloader	Downloaders for various source types.	docs
	Xcodeproj	Create and modify Xcode projects from Ruby.	docs
	CLAide	A small command-line interface framework.	docs
	Molinillo	A powerful generic dependency resolver.	docs
	Master Repo	Master repository of specifications.	guides

cocoapods-repo-shard's Issues

Dependabot can't resolve your Ruby dependency files

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::VersionConflict with message: Bundler could not find compatible versions for gem "escape":
  In Gemfile:
    cocoapods (>= 1.0.0.beta.7) was resolved to 1.6.0.beta.2, which depends on
      escape (~> 0.0.4)

Could not find gem 'escape (~> 0.0.4)', which is required by gem 'cocoapods (>= 1.0.0.beta.7)', in any of the sources.

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Backwards compatibility

As discussed in this blog post, sharding the master repo introduces backwards-incompatible changes. In our organization we share CI servers and use Bundler along with a Gemfile to specify versions for dependencies, but different versions share the same ~/.cocoapods directory.

This hasn't been a problem in the past, but with the introduction of sharding it looks like we will no longer be able to share the same ~/.cocoapods with projects that haven't been updated to Cocoapods 1.0.0.

Looking through the CLI I haven't found a mechanism for specifying a custom ~/.cocoapods directory, which would allow us to have a legacy directory and one for 1.0.0. Is such a thing possible?

That being said, separating directories seems like only part of the problem because old versions of Cocoapods will try to update their specs repo but will get the new sharded version which they can't parse. Perhaps there is a way to "freeze" these legacy projects so they don't update their copy of the specs repo. Or would you recommend we fork the repo in it's current state and update these legacy projects to use that fork in favour of the sharded repo?

I'm sorry if this isn't the right location for such questions, I could move it to the Cocoapods repo if that would be preferable.

Release

After 1.0.0.beta.7 is out in the wild

Please Document the Sharding Algorithm

I'll be honest, my ruby-foo sucks. Between the trunk repo and this repo I'm having trouble source diving exactly how the sharding works, and having some brief documentation on the strategy would be awesome.