Sometimes we don't actively rely on related components in order to pu…

[ymoyao]

Sometimes we don't actively rely on related components in order to push tags quickly, but indirectly through protocols! However, this disconnects references between components, which can be missed when a dependency is needed, so to avoid this, after the dependency, added: virtual => 'true' to mark as virtual dependency. The dependency is not associated with the component when the tag is pushed, but is imported in pod install/update and other cases. This allows for both quick push of the component tag and strong binding between components. Now, we can mark the virtual dependencies like this 'Spec.ios.dependency' MBProgressHUD', '~> 0.5', :virtual => 'true'; we really need this, please help merge into the code, thank you very much

[orta]

This is usually something that subspecs handle, I'm not too convinced we need a different DSL attribute to describe optional dependencies

[ymoyao]

thanks for rely
the importent is speed of repo push, too much subspecs or dependency will drag tab push speed. Unfortunately！our company has more than 10 apps, these apps share some components, and a component that has more then. 10 subspecs will take more than half an hour to push,So in our project,we decouple dependency between some business component. such as: origin is A dependency B, A can call B api directly. Now, we de-dependence A and B, A call B api In some dynamic way such as target action.
finaly, we use dependencies directly on capability-related components because the logic is simple enough, the subspecs and dependencies are small enough, and the push repository is fast enough. However, in the complex code business layer components, each push will consume a lot of time, very uncomfortable, I believe that some people will also encounter this problem, might as well add a new feature to try? It will help some people!