-
Notifications
You must be signed in to change notification settings - Fork 349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List all desired subspecs on one line in Podfile #221
Comments
We'd actually rather encourage people to not use subspecs :) |
What would you suggest as an alternative for situations like this? |
Runtime customization? -Samuel E. Giddins On Feb 25, 2015, at 8:25 PM, Mickey Reiss notifications@github.com wrote: What would you suggest as an alternative for situations like this? — |
Since this is Ruby and it's a full language, a short term solution for this that you can currently use with CocoaPods: %w(Scissors Machette).each{ |s| pod "CuttingTools/#{s}" } Perhaps the proposed syntax, or a similar syntax makes sense to simplify subspec use. @orta any input? |
@orta do we want to add this to the DSL? |
Oh wow, I have never even thought of this. It'd be lovely IMO. |
Similar to #150, I am also hitting a point where some sugar on top of subspecs would be useful.
In my case, I'd like to have a single Pod with ~5 optional subcomponents. Each user of the pod is likely to choose a different subset; it's nearly impossible to determine what the right set of defaults should be. By choosing a subset for people, we likely introduce bloat into typical integrators' apps.
In this type of setup, where subspecs are closer to build variants than separate components, I propose a syntax that allows the user to specify all relevant subspecs on one line in their
Podfile
:as an alternative to
You'll note in this example that
KnifeBlock
has a hierarchical relationship with the rest of the subspecs, in that it holds whichever knives happen to be available; at the same time, if KnifeBlock pulls in every tool (subspec) available as a dependency, many users will end up with extra code provided by the unused katana, butter-knife, etc. (i.e. undesired subspecs for that application).Has something along these lines been considered in the past?
The text was updated successfully, but these errors were encountered: