Clean paths for ad-hoc/pre-downloaded dependencies

[zwaldowski]

I've moved towards pre-downloading some dependencies for repos that I work on in lieu of rolling my own inline spec, like so:

dependency 'BlocksKit',
  :git => 'git://github.com/zwaldowski/BlocksKit.git',
  :commit => 'origin/next'

I don't know if this is any kind of official feature, but I find it massively useful. However, I'm having one major problem with its use. CocoaPods does seem to be parsing the spec for the pre-downloaded pod (as evidenced by Using RepoName (Version) later on down the line), but it's not cleaning out paths for these pre-downloaded repos, leaving behind a ton of unit tests, etc. Any thoughts?

[alloy]

Yup, it’s an official feature. It’s aimed at allowing people to use the bleeding edge of a pod, if it has a pod spec in the root of the repo. This can also be a git submodule, although we don’t have code yet that adds the submodule to the user’s repo.

What happens is that cleaning occurs only once, which is just after a pod has downloaded. If the directory already exists, it doesn’t download nor clean. This allows a submodule to happily co-exist and CocoaPods will just use that, but without cleaning it. Automatically cleaning would have to mean we’d have to have code in place to know whether or not a directory is a submodule, because clearly you don’t want to perform a clean in a submodule.

So I assume in your case you just want the code of the other library in the actual repo? If so, for now you could do it by removing the pod’s dir (BlockKit in this case) and running pod install. This should grab the latest version of BlockKit and perform a clean.

[alloy]

Since there are already tickets about things like submodules, I’ll close this as a duplicate. Feel free, however, to create tickets about your preferred workflow, or add it to existing tickets.

[zwaldowski]

Right, I gathered that much by skimming through the pre-downloading code. But my problem is that, on my end, it's never doing any form of cleaning at all, initial or not. You can look at my before and after results.

[alloy]

Oh, hmm, that ain’t right indeed. I’ll reopen the ticket.

[lukeredpath]

This should be fixed in fd02d56.

I've double-checked to make sure that no cleaning occurs if the directory already exists (e.g. it's a submodule). Cleaning now takes place when pods are pre-downloaded.