Skip to content

Files/groups are duplicated for each target #376

Closed
alloy opened this Issue Jul 6, 2012 · 17 comments

3 participants

@alloy
CocoaPods member
alloy commented Jul 6, 2012

This is probably an issue with Xcodeproj.

See:

@fabiopelosin
CocoaPods member

Do you still experience this issue? I haven't encountered it yet.

@jakeboxer

I'm having this issue too, but it's on files, not on directories.

See:

@alloy
CocoaPods member
alloy commented Aug 22, 2012

I think this might have to do with having multiple targets that inherit dependencies from each other, but I don’t remember. @jakeboxer is that your case?

@jakeboxer

@alloy I do have two targets; one for regular stuff (development and App Store submission) and the other for TestFlight distribution. I don't think they inherit dependencies from each other, but they do both have the same dependencies (since they build the same app).

@alloy
CocoaPods member
alloy commented Aug 22, 2012

@jakeboxer Can you paste your Podfile so that we know for sure that we’re on the same page?

@jakeboxer

@alloy yep, here it is:

platform :ios, '5.0'

pod 'iCarousel',           '~> 1.6.3'
pod 'ShareKit/Facebook',   '~> 2.0'
pod 'ShareKit/Tumblr',     '~> 2.0'
pod 'TTTAttributedLabel',  '~> 1.2.2'
pod 'NYXImagesKit',        '~> 2.1.2'
pod 'iRate',               '~> 1.4.7'

target :test do
  pod 'GHUnitIOS',       '~> 0.4.33'
  pod 'OCMock',          '~> 2.0.1'
end
@alloy
CocoaPods member
alloy commented Aug 22, 2012

@jakeboxer Right, so because your :test target does not have the :exclusive => true option, it inherits all the dependencies of the top level target. You did not expand the GHUnitIOS and OCMock groups, but I’m guessing that they don’t contain duplicates, correct?

@jakeboxer

@alloy yep, that was it. GHUnitIOS and OCMock weren't duplicated, and when I added :exclusive => true, it fixed it. Thanks a bunch!

@alloy
CocoaPods member
alloy commented Aug 23, 2012

@jakeboxer Good to know, thanks. Note, though, that while this setup might work for you, the original issue still needs to be fixed. The files should not be duplicated when a target does need to inherit dependencies.

@fabiopelosin
CocoaPods member

I think that the problem is in Pod::Installer#pods_by_spec. An I think that the problem is bigger than what it appears. Basically a pod is created for every target and Pod::Installer#pods doesn't take into account this. For instance in Installer#project the relative files of a pod are added as many times as the targets that depend on it.

The issue is much deeper though. For instance if a pod is required by a two targets which activate different subspecs (maybe because some subspecs work only in one platform), with the current implementation the first one that gets intalled wins and cleans all the files that it doesn't uses.

I think that the best solution is to create an object that aggregates the pods the pods that originated from the same top level specification and that should take care of providing all the files removing any duplicates. Something like PodSet or PodCluster. It should have a similar interface of the LocalPod, so when we need to do operations with targets we can work with the pods directly and when we need to do an operation once for a given Pod we can use the cluster.

Makes sense?

@alloy
CocoaPods member
alloy commented Aug 24, 2012

@irrationalfab I think it makes sense. Could you maybe first add some failing tests that cover the problematic areas so that we know we’re exactly on the same page?

@fabiopelosin
CocoaPods member

Added in the duplicated_files branch.

@fabiopelosin
CocoaPods member

See 5690b44.

@alloy alloy closed this in 0da6c35 Aug 25, 2012
@alloy
CocoaPods member
alloy commented Aug 25, 2012

Ok, I’m not sure about the concerns for an extra class, isn’t this enough?

@fabiopelosin
CocoaPods member

I don't think so, because if the pods includes different activated subspecs only the last one installed would have the files.

This is the case for pods that include different subspecs for ios and osx.

@fabiopelosin fabiopelosin reopened this Aug 25, 2012
@fabiopelosin
CocoaPods member

@alloy I remember there was a podspec that worked in OSX and iOS but had a subspec that was not compatible in iOS. However, I can't find it. Considering that the edge case where one activates different subspecs for different targets is very rare I think that we can consider this an example of premature optimization. So I changed my mind and now I agree with you that the uniq should suffice.

Lets see if somebody opens an issue about it in the future.

@alloy
CocoaPods member
alloy commented Aug 25, 2012

I don't think so, because if the pods includes different activated subspecs only the last one installed would have the files.

This is the case for pods that include different subspecs for ios and osx.

Hmm, I still don’t follow the issue completely. All LocalPod instances should come from the sandbox, which caches them and they are looked-up by the top level spec, so they should always be the same instances.

So I changed my mind and now I agree with you that the uniq should suffice.
Lets see if somebody opens an issue about it in the future.

Ok. If it’s simple enough to express the issue you have in mind in a test, then please do, so I can understand the issue fully. If it’s going to be hard, then never mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.