Dependency link

[fabiopelosin]

My attempt to take full advantage from the workspace feature. It is just an external source that works by making a symbolic link. I tested it a bit and seems to work. But I'm not sure what would happen in edge conditions (e.g. if somebody mixes it with a local pod). As, usual is still missing tests.

Usage

in the podfile:

dependency 'Reachability', :link => '/Users/fabio/libs/Reachability'

Previous discussion at #178 - #179.

[alloy]

I completely missed your last comment in #178, sorry about that.

I’m on the fence about this. I agree with you that live-editing is very important, but I’m thinking that if one would use, for instance, a git submodule in ./Pods, than you can have the ability to live-edit and commit, while still having a Podfile that can be shared with other collaborators without them having to have a checkout at some arbitrary location on disk.

So my suggestion for this is something like:

dependency 'MyAwesomeLib', :git => 'GIT URL', :submodule => true

This would fetch the lib from the GIT URL like normal, but instead of cleaning out the .git directory it would add it as a submodule to the git repo that the project is in. (Or just not clean if the current repo is not a git one.)

As a matter of fact, this is how I have been doing it since the beginning, but I had to create the submodule manually and then afterwards run pod install so that it would not clean the .git directory.

[alloy]

@kommen, @lukeredpath, @subdigital What do you guys think?

[fabiopelosin]

Ok, I have been overcomplicating this... sorry for the noise. Now I see that a simple pod install --no-clean would do for my needs.

However, I have two points which are still unclear:

• is there any advantage gained by using a submodule respect to git-ignoring the Pods folder?
• why pods are cleaned by default? Right now I think that, except in rare cases, the pods don't have a significant impact in the disk usage and so it might be more appropriate to preserve the repos by default.

s/overcomplicating/proposing a stupid solution to/ :-)

[alloy]

Ok, I have been overcomplicating this... sorry for the noise.
s/overcomplicating/proposing a stupid solution to/ :-)

Nothing stupid about it! I should have catched what you were trying to do earlier to save you from this work. Nonetheless, normally I love to discuss patches instead of theories :)

• is there any advantage gained by using a submodule respect to git-ignoring the Pods folder?

So, personally I add the Pods directory to the project repo, because:

• Fingertips (my employer) is a consultancy. I want the client, or any other dev on the project, to be able to do a checkout and build, without having to worry about details like running pod install.
• Currently pod install does not check Podfile.lock yet for the version that was installed previously. So, unless you have hard version requirements for specified for your dependencies, every time you run pod install it will fetch the latest version. This might not be what you want, as it could ‘suddenly’ break your build (API changes, etc). This will be fixed with Add pod update command #131.

• why pods are cleaned by default? Right now I think that, except in rare cases, the pods don't have a significant impact in the disk usage and so it might be more appropriate to preserve the repos by default.

Because:

• Git does not like it when you add a git repo to a git repo, unless you add it as a submodule.
• If you include Pods in your repo, like I do, than you will have many files that only clobber up the repo.

[fabiopelosin]

Very reasonable points. Now I agree with you that using submodules is the way to go.

What about Added resolved depenencies tree to verbose install (0bd8ffe) and Changed Sandbox#installed_pod_named behaviour (c8132a2 - 15c4ca3 => this one has a bug). Should I add them to master?

[alloy]

Alas, I must admit that my knowledge with regards to the local pod code is not up-to-date yet. @lukeredpath Can you take a look at those changes when you have some time?