Carthage: Add a solution for vending binary-only frameworks

[mdiep]

Some commercial frameworks are vended as binaries only.

[tcurdt]

This issue does not capture the intend very well. This original request has only little to do with commercial vs non-commercial. And maybe at least reference https://github.com/Carthage/Carthage/issues/722 ?

[grangej]

We need to be able to support specifying direct path for a binary resource that works exactly as the way the github does exact we specify the full path to the binary.

I have checked out romebuild etc this does NOT do what we need it to do, it only caches the whole module, so if we have to rebuild the module because it was updated we again have to build all the sub modules even though they were already cached.

This is maddening. It takes 20 mins for me to do a stupid simple change.

[flovilmart]

@mdiep

PROPOSED SPEC:

For the Cartfile:

http "<URL>"

• keyword http would indicate a direct download of the file a the URL
• URL should be enclosed in double quotes
• version, branches and other trailing chars after the URL should be considered faulty configuration
• the file hosted at the URL should be a zip file
• the zip structure should be produced by carthage build --no-skip-current && carthage archive
• the zip file should be uploaded to the host as is
• Ideally the download, cache, copy, extraction should be exactly the code in place for Github releases
• If the file is unavailable, the download fails or any other error occur, carthage should fail
• the commands carthage update and carthage install should 'dumbly' fetch the latest versions on the host. it's up to the framework provider to handle versioning of it's frameworks.
• Suggestions for a 'clean' hosting:

http "https://my.domain.com/release/0.0.1-alpha/framework.zip"
http "https://my.domain.com/release/1.0.0/framework.zip"
http "http://my.domain.com/1.0.0/framework.zip"

http and https should be supported

Suggestions?

[sstadelman]

@flovilmart This looks reasonable. The carthage archive product would work.

I would propose the alternate keyword src, vs. http. src has the nice precedent in HTML of containing the URI of the required resource, be it a script, image, or frame content. Web User Agents support both fully-qualified and relative URI variants. In the Cartfile domain, a relative URI would be nonsensical, and it would be obvious to developers to use the fully-qualified URL.

That said, http is pretty intuitive as well.

Moved from #722

At SAP, we would really like to see this feature available, to let Carthage users update framework dependencies with Cartfile-based rules, as we publish updates. We do have a github presence, but our release policies dictate that only Open Source-licensed content can be distributed via the site. Instead, we would prefer to make the frameworks available from our regular tooling site: https://tools.hana.ondemand.com/#mobile.

Parsing the thread above, it looks like the main blocking issue is the lack of semantic versioning on unknown remote sources. You point out that Github Releases does support this, which logically contributed to implementing the feature originally. That makes sense. But, maybe there are some acceptable limitations to versioning which could be unique to non-github sources?

A. Should remote sources also implement semantic versioning, according to the Github API Releases spec? If this were adopted, we could propose requiring the following services?

GET /:repo/releases
GET /:repo/releases/:id
GET /:repo/releases/latest
GET /:repo/releases/tags/:tag
B. Scratch semantic versioning for remote sources. The framework provider may version the *.framework.zip according to their own preference, but Carthage does no enforcement. Ironically, the model for this is jQuery on the Google CDN, where "automatic version aliases" were deprecated, and developers should now supply full-qualified version URLs.

For our customers, we think that (B) would be quite acceptable. ((A) might also be possible--and very nice). (B) would be a short, pragmatic approach, and solve the basic problem of allowing all dependencies to be aggregated when using carthage update.

[mdiep]

I think semantic version remains important. Without dependency resolution, you lose much of the benefits of Carthage.

Something like this seems before beneficial:

zip "https://my.domain.com/framework.json" ~> 1.0

Where framework.json is something like this:

{
  "1.0": "https://my.domain.com/release/1.0.0/framework.zip",
  "1.0.1": "https://my.domain.com/release/1.0.1/framework.zip""
}

That would allow Carthage to continue using semantic versioning.

HTTPS is required because the possibility of injecting code through a MITM is quite scary.

[sstadelman]

@mdiep the framework.json is a Carthage-managed file (related to the Carthage cache)? Or developer-supplied...?

• We would be ok with this path-driven naming convention. I don't see it as critical, but it would be nice to have versioning available if feasible.
• https requirement is fine

[mdiep]

@sstadelman It would be provided by the framework author.

[sstadelman]

@mdiep ok, and we'd host that file in the release/ root?

[mdiep]

You could host it anywhere—it's the URL that consumers would put in their Cartfile. Then releases could live anywhere. Carthage would find them from the JSON file.

[sstadelman]

That works great for our model.

[TheElter]

+1
We have the same trouble for an internal framework that cannot be distributed through GitHub

[BennettSmith]

I'm curious what the status of this issue is. If I'm interpreting the comments above correctly, it looks like there is a solution in the works, but not much movement in the past month or so. I would love a solution to this issue, as we really want to adopt Carthage but cannot until we have some way of referencing binary frameworks.

[mdiep]

I suggested an acceptable approach. AFAIK, no one is working on implementing it.

If this is important to you or your company, I'd suggest implementing it yourself or sponsoring someone to implement it. ☺️

[JonB]

I have started some initial work on this, but currently trying to get my head around CarthageKit's structure. Once i've made a bit more progress I'll open a PR for feedback

[peternashdrayson]

Looking forward to this, I'm looking to integrate this for GoogleMaps SDK for iOS.

podspec https://raw.githubusercontent.com/CocoaPods/Specs/master/Specs/GoogleMaps/2.1.0/GoogleMaps.podspec.json

https://www.gstatic.com/cpdc/0646cf0bd434ed77-GoogleMaps-1.10.1.tar.gz

[lucaquerella]

Is there any update on this?

[michaelmcguire]

I'm working on this and should hopefully have a PR open this week

[mdiep]

1760 has been merged, which adds support for this. It will be in the next release! (Soon.)

[JetForMe]

Does this allow me to create a Carthage-supporting Framework from a third-party .dylib and header file? We have this dependency, but it's a pain to use because it's not packaged as a Framework.

[mdiep]

It would need to be packaged as a framework

[lukewakeford]

I've just hit this roadblock as well. I want to use Carthage to handle dependencies for an internal library, but this library depends on some closed-source projects like google analytics.

Did adding binary only framework support make this possible? re: #1426