Check out dependencies specified in Cartfile about carthage HOT 15 CLOSED

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

from carthage.

I like checkout.

from carthage.

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

from carthage.

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

from carthage.

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

from carthage.

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?

from carthage.

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.

from carthage.

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?

from carthage.

@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.

from carthage.

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.

from carthage.

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.

from carthage.

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.

from carthage.

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

👍

from carthage.

I might take stab at this... :)

from carthage.

I might take stab at this

from carthage.