grab / grab/cocoapods-binary-cache

[Idea] Centralized Cache

Open
#62 1 comment 2 reactions 0 assignees View on GitHub
Dominant language
Ruby
Stars
488
Forks
69
PR merge metrics
No merged PRs in 30d

Description

I really love your plugin and its a massive time saver :blush:

I just want to share my basic idea which would lead to a massive change in the architecture and workflow of the plugin.
On the other hand I could bring use a centralized cache :)

I would be nice I you could share your thoughts on this.

### Workaround for Realm
I had some trouble with Realm (https://github.com/grab/cocoapods-binary-cache/issues/57).
While I was not able to resolve these issues I reworked them by creating a "binary pod" of Realm.

I prebuilt it myself (which is pretty easy but a manual task...) and put it on a interal git repo, than I created a Podspec which uses the internal podspec repo together with the offical cdn repo.
By this the official Realm/RealmSwift Pod is overruled with my internal binary version.
The clou:
I also use RxRealm, which depends on RealmSwift. By overriding the dependency with a binary version, the pod resolution still works.
This "workaround" made me thinking, if we could create a more global, not project specific binary cache. The global cache could work more like a maven repository.

A few preconditions for this, for making the cache relatively stable:
* host xcframeworks
* build all archs
* build with library evolution support

I've built my binary repo with this basic scheme, mirroring the podspec repo:
PodName/Version/PodName.xcframework.zip

i.e:
Realm/10.5.1/Realm.xcframeworks.zip
RealmSwift/10.5.1/RealmSwift.xcframework.zip

I created Podspecs like these:

```
Pod::Spec.new do |s|
s.name = 'Realm'
s.version = '10.5.1'
....
s.platform = :ios, '11.0'
s.source = { git: 'binary_pods.git' }
s.ios.vendored_frameworks = "#{s.name}/#{s.version}/#{s.name}.xcframework"
end
```

In the Podfile there are two ways to use this:
` pod 'Realm', '10.5.1', source: 'cocoapods_binary_specs.git'`
or
```
source: 'cocoapods_binary_specs.git'
pod 'Realm', '10.5.1'
```
However this will trigger a warning, that i.e. the Realm pod is found multiple sources. This can be silenced with by setting `warn_for_multiple_pod_sources`.

This is just a basic example, but it shows how we could basicly overwrite any source code dependency with a binary verison.

### Basic proposal
Currently we have a binary cache per project, which cannot be versioned.
Cached artifacts, cannot be shared.
We have nothing like a "maven repository".
I want to keep the changes to the podfile minimal by only adding a new source (no explicit pod_binary).

`pod binary prebuild --push` behavior:
option 1, prebuild all pods:
* builds all dependencies as xcframeworks for a specific Podfile
* searches all pods and find dependencies
* tries to build every pod

option 2, prebuild a single pod:
`pod binary prebuild --push Resolver:1.4.0`
find a pod and build that exact version.
also build all dependencies of the pod.

* binaries are added versioned (like Realm/10.5.1/Realm.xcframeworks.zip) to the central cache
* create binary Podspecs and push them to cocoapods_binary_specs.git
* add transitive dependencies to the generated binary Podspecs

### Usage
* Podfile has an additional source i.e. source: 'cocoapods_binary_specs.git'
* now "binary_pod" function would be used explicitly
* cocoapods_binary_pods would not integrate the xcframework itself, since the specs from cocoapods_binary_specs are used

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.