Check out dependencies specified in Cartfile

[jspahrsummers]

We should clone dependencies—and their dependencies’ dependencies—while trying to find the versions of everything that match what's specified in the config.

Where would these checkouts live? A global folder, or something inside the repository? The latter could be useful if you want to commit your dependencies (to protect against them disappearing).

[jspahrsummers]

Should this be carthage setup or carthage checkout or something like that?

[mdiep]

I like checkout.

[mdiep]

We could put this in the project's derived data.

$ xcodebuild -showBuildSettings|grep BUILD_DIR
    BUILD_DIR = /Users/mdiep/Library/Developer/Xcode/DerivedData/GitHub-deqblmyehxiqojaxxezbskyigcce/Build/Products

[jspahrsummers]

I personally clean my DerivedData folder fairly frequently. I'd hate to lose a bunch of expensive Git clones just because of that.

[robrix]

Run script phases & other things frequently mash around in there, so we’d want to avoid collisions.

[jspahrsummers]

I'm currently leaning toward storing these checkouts within the repository itself, to allow users to commit them if they want to.

Similarly, I don't think git submodules will work for this case, because we want them to be committable as-is, and we don't want users to accidentally clone recursive submodules when we're managing these repos for them.

So, maybe we can create a bare clone in a private, global folder (a la Cabal), and checkout that clone into the repository folder?

[mdiep]

Similarly, I don't think git submodules will work for this case, because we want them to be committable as-is, and we don't want users to accidentally clone recursive submodules when we're managing these repos for them.

I was going suggest that we store them as submodules and let the user specify which directory the go in. I don't understand the points you're trying to make here.

[robrix]

So, maybe we can create a bare clone in a private, global folder (a la Cabal), and checkout that clone into the repository folder?

Sorta like git-subtree --squash?

[jspahrsummers]

@mdiep My point is, if you want to commit your dependencies into your repository to prevent them from disappearing (which is especially important for consulting), submodules aren't an option, because they rely upon an external reference remaining valid.

If, however, we allow them to commit the content of dependencies, they'll at least have the code if the repositories go AWOL.

Sorta like git-subtree --squash?

@robrix I guess, but the difference is that we can share Git clones with multiple Carthage projects if we centralize some bare clones, and then simply git checkout the desired commits into the actual project folders.

[mdiep]

My point is, if you want to commit your dependencies into your repository to prevent them from disappearing (which is especially important for consulting), submodules aren't an option, because they rely upon an external reference remaining valid.

If, however, we allow them to commit the content of dependencies, they'll at least have the code if the repositories go AWOL.

Ugh. I really hate that. Diffs get nasty. You lose the niceness of submodules on .com. If you want to make sure the references remain valid, you should fork it or keep a copy somewhere.

[jspahrsummers]

Diffs get nasty.

If you don't want to commit your dependencies, you can just .gitignore the folders we check out. Easy peasy.

You lose the niceness of submodules on .com.

The Carthagespec diff is what's canonical anyways, so it seems like submodule diffs would just be distraction/duplication.

[mdiep]

The Carthagespec diff is what's canonical anyways, so it seems like submodule diffs would just be distraction/duplication.

Except it's "hard" to go from a carthagespec to browsing the repository/tree. And I'm hoping that submodule diffs will someday link to a compare view.

[mdiep]

If you don't want to commit your dependencies, you can just .gitignore the folders we check out. Easy peasy.

👍

[alanjrogers]

I might take stab at this... :)

[jspahrsummers]

I might take stab at this