Add possibility for Podfile.local

[abrausch]

We wanna have a local developer only Podfile to handle for example this case:

Normally all developers should use the project specific Podfile which is in our git repo. But if a single developer now wants to work on a dependency of that project, we wanna create a "local" Podfile which is include in the .gitignore. In this local Podfile the developer can then for example specify something like this:

pod "blabla", :local => '......'

[coveralls]

Coverage decreased (-0.57%) when pulling 30387d3 on abrausch:master into bfb9870 on CocoaPods:master.

[alloy]

We agree that this situation should be improved, but we’re not yet clear on the exact path. Our internal discussion on the topic can be summed up as follows:

What we need is a way to override the source location for a requirement in the Podfile, but without affecting files that could be checked-in into SCM. E.g. Podfile, Podfile.lock, and everything in the Pods directory.

In your current PR, the Podfile.lock file would still get modified, so you can’t have it in SCM without affecting other users of the repo.

We would love more input, especially from a working solution. Taking that into account, I would suggest you make use of the fact that a Podfile is a Ruby source file and add logic for your specific situation there. Once you have something that has been demonstrated to work in your company’s setup for a while, we can then discuss further based on a working solution, instead of all theoretical issues.

As a start, here’s a very contrived example on how to do what your PR does from the Podfile:

if File.exist?('Podfile.local')
  eval(File.read('Podfile.local'))
else
  # normal definitions used by everyone else
end

Keep in mind that with Ruby it is possible to monkey-patch everything at runtime, so it should all be possible from your Podfile.

[fabiopelosin]

In your current PR, the Podfile.lock file would still get modified, so you can’t have it in SCM without affecting other users of the repo.

Another area of improvement is that it shadows the Podfile, when the user wants just indicate that he would like to use only certain dependencies from a local source.

[alloy]

Another addendum: in Bundler you can specify an alternate Gemfile with the env var BUNDLE_GEMFILE. Bundler in turn will save a lockfile based on the Gemfile’s name, instead of hardcoding a lockfile name. This is at least a viable solution to dealing with the lockfile.

[abrausch]

In your current PR, the Podfile.lock file would still get modified, so you can’t have it in SCM without affecting other users of the repo.

Sorry just for clarification. In the core project there is no link to the Podfile.lock. So I have to change that with the corresponding patch in Cocoapods. Am I right?

[abrausch]

I would like to help, but I think in our situation we need to also create a local ".lock" file. Because we do not want to commit local configurations to out vcs. Because it is possible that 4 internal developers and one freelancer work on the same project. All should start with the Podfile from the server. And if I understand it right, also the Podfile.lock should be inside the server repo. So now all five developers have the same standard configuration. Now developer A starts to change also local library code of library B and developer C starts working on library A. So either developer A nor developer C should send any Podfile specific changes to the server. So in out case it would be better if for example developer A could use something like this:
pod -f Podfile.local install
and as a result there should be also a Podfile.local.lock. Another way would be to set an environment variable like BUNDLE_GEMFILE to set the name of the podfile (and the lock file). Or perhaps create something like rbenv ".ruby-version" to specify the podfile name.
Can you perhaps explain me why you prefer a solution like the local git repos in bundler?

Thanks in advance

[fabiopelosin]

I would like to help, but I think in our situation we need to also create a local ".lock" file

Great.

Can you perhaps explain me why you prefer a solution like the local git repos in bundler?

The solution proposed in this pull would shadow the Podfile and the Podfile.lock and thus offers little benefit to keep those file dirty in git (see temporarily ignoring files). Moreover, it would be great to get this feature right from the start, as changing implementation later on would create issues.

In my opinion we should allow to specify that the source used by some Pods should point to a custom path/repo. This can be done by introducing another config file and/or a dedicated command as Bundler does. Bundler implementation moreover is more robust because it updates the Lockfile (which is under source control) to store the last SHA of the specified repo. This greatly limits the risk that the installation performed by other clients would use a different version of the modified Pods.

For example, taking into account two devs (A and B) and two libs (1 and 2).

• Developer A starts to work on lib 1 and commits changes to the client project and to the server.
• The changes committed to the project build only with the changes of the last commit of lib 1.
• In the meanwhile, developer B is working with lib 2.

With the solution of Bundler, the Lockfile would point to the last commit of lib 1 automatically. This mean that the build doesn't break on CI. Moreover, if dev B merges the head of origin/master in his branch he can continue his work undisturbed without trying to understand what broke the build.

[fabiopelosin]

Moving to CocoaPods/CocoaPods#1010

[hfossli]

This is great!!!!

if File.exist?('../transitioner-ios')
    pod 'AGSViewTransitioner', :path => '../transitioner-ios'
else
    pod 'AGSViewTransitioner'
end

if File.exist?('../services-ios')
    pod 'AGSServices', :path => '../services-ios'
else
    pod 'AGSServices'
end

[orta]

The present discussion about this is here: CocoaPods/CocoaPods#1482