Carthage: Have a way to obtain pre-built Frameworks

[robb]

E.g.:

download "https://s3-eu-west-1.amazonaws.com/lookback-public/sdk/lookback-sdk-0.6.5.zip"

[jspahrsummers]

It'd be pretty easy to use GitHub Releases for this purpose, since those binaries are associated with tags.

I'm not sure how we'd do it in the absence of any versioning, though. For example, how do we know that two zip URLs are actually the same project, but different versions?

[robb]

Couldn't we treat them the same we'll treat two pinned SHAs?

[jspahrsummers]

Two pinned SHAs:

1. Can clearly refer to the same repository. Two pins in github "ReactiveCocoa/ReactiveCocoa" at least give us something to work with.
2. Refer to objects with Git histories, so we can do _something_ to see if those histories satisfy some vague notion of “compatibility,” like checking whether one is the merge-base of the other.

Arbitrary zip URLs don't definitively refer to the same project, and have no associated version information.

[robb]

True dat.

Let's say this Origin needs to be pointed at a .framework inside a zip file, we could the inspect the bundle identifier and version strings of said Framework, couldn't we?

(For the above Lookback example, there are unfortunately mutually exclusive .frameworks in different subfolders but that we don't have to deal with, I think)

[jspahrsummers]

Let's say this Origin needs to be pointed at a .framework inside a zip file, we could the inspect the bundle identifier and version strings of said Framework, couldn't we?

Hmm, maybe. Though we'd have to do that for all possible _candidate_ versions, to determine which is the most suitable. That sounds fairly intensive/tricky. :worried:

At this point, I wonder if it's just simpler to ask users (like yourself :stuck_out_tongue:) to create a repository that simply hosts Releases of the project. It's an easy workaround, but flexible—and it makes the tooling so much simpler.

[robb]

Yeah, this get's nasty :unamused:

Alternatives could be to supply the version with the URL in the Cartfile or simply not having any conflict resolution. The latter would work given the Lookback example, since that's very unlikely to be a transitive dependency.

[jspahrsummers]

If it won't ever be a transitive dependency, and it's a binary anyways, what's the advantage to using Carthage? At that point, I'd say it's easier to commit the binary to the repo.

[jspahrsummers]

Tentatively closing per my above comment, but we can reopen this and continue discussion if that doesn't sufficiently address the need here.

[dodikk]

At this point, I wonder if it's just simpler to ask users (like yourself :stuck_out_tongue:) to create a repository that simply hosts Releases of the project. It's an easy workaround, but flexible—and it makes the tooling so much simpler.

It will take ages to clone a repository full of BLOBs. Try the "iOS-openssl" for example.
https://github.com/st3fan/ios-openssl/tree/master/lib

[dodikk]

For example, how do we know that two zip URLs are actually the same project, but different versions?

Why should you care about it? Carthage leaves the integration and linking to the user. Doesn't it? Download location uniqueness can be ensured by framework's info.plist parsing (as mentioned by @robb )

[dodikk]

If it won't ever be a transitive dependency, and it's a binary anyways, what's the advantage to using Carthage?

Suppose, I want to build a framework on top of Flurry or Google Analytics which are not open source frameworks. Let's imagine for now they do support the "binary framework" distribution form.

You suggest committing them to my framework's repo which is not a good solution (see openssl-ios example above). Otherwise my framework just won't build.
P.S. "Committing only headers" works only for static frameworks. Not dynamic ones.

[jspahrsummers]

It will take ages to clone a repository full of BLOBs.

That's not what I described. I described adding a _GitHub Release_ with the attached binaries.

Why should you care about it? Carthage leaves the integration and linking to the user. Doesn't it?

Yes, but part of Carthage's responsibility is to ensure that you only have one copy of any given dependency.

[robb]

That's not what I described. I described adding a GitHub Release with the attached binaries.

As someone who has to pay for their GitHub repositories, I'm a little less inclined to create on of those for any closed-source, binary dependency I have to happen ;-)

[jspahrsummers]

@robb Well, Releases on repositories aren't the _only_ option—just the one I would default to. And if your dependency is publicly available (even if closed source), you should still be able to create a public repo with Releases for it.

[robb]

Yeah, I was mostly kidding.

How about an Origin that points at some form of Manifest file which contains information equivalent to what the GitHub API has for Releases? (That's like tag, zipball_url, name?)

That way, they could both share the same download and extraction mechanisms.

[jspahrsummers]

Let's implement GitHub Releases support first. All the speculative feature development is painful. :stuck_out_tongue:

[virl]

@jspahrsummers @robb
Hi.
How can I publish closed source binary framework so it can be installed via Carthage?