-
Notifications
You must be signed in to change notification settings - Fork 105
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
Add Settings.bundle containing acknowledgements if CocoaPods is enabled #191
Conversation
Afterthought: I should still add an option to the cli to allow anyone to enable/disable this feature. |
Did quite a refactor to be able to put everything behind the enable_settings option. Downside is that you lose the flexibility of specifying where the Settings.bundle should go in your project structure (but that's not that big of a tradeoff I guess, except that it assumes a 'Resources' group). Also note that the Any feedback & assistance is appreciated @gfontenot, since I am pretty new to Ruby & this project. Keep up the good work, this is an awesome tool and I'd love to contribute even more. |
Slick. Thanks for this. I'm wondering if we shouldn't make the acknowledgement bit conditional to CocoaPods being enabled. That would give users a bit more control over the setup of their project. They could (for example) keep the settings bundle enabled, but disable CocoaPods and end up with an empty settings bundle, or they could disable the settings bundle and keep CocoaPods enabled and end up with no attribution. |
Good point, you're correct that users will now end up with an empty Acknowledgements sections if they decide to disable CocoaPods support. I'll have to look into how I can dynamically include/exclude this from the Root.plist. Or maybe I could supply two different Setting.bundle files in the templates folder (one with and one without the Acknowledgments section) & move one or the other depending on what the user chose. I'll have a look at this later today. Note that the Settings.bundle will never be empty, there's always going to be a Version entry. Should this be optional as well? |
You can use ERB for this fairly easy. A conditional block in ERB would look like this: <% if use_cocoapods %>
# stuff
<% end %> Note the lack of Regarding the version entry: I feel like I'd prefer to not include that by default. It's something that can easily be overridden in a custom plist locally if needed. |
Thanks, I'll update this pull request with your feedback as soon as I find the time. |
I removed the automatic addition of version info & updated the file manager so that files inside directories get parsed as well (needed to use ERB inside Root.plist of the Settings.bundle). |
@@ -88,7 +88,7 @@ def linkable_file?(name) | |||
end | |||
|
|||
def resource_file?(name) | |||
name.end_with?('xcassets') | |||
name.end_with?('xcassets', '.bundle') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need the .
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will fix.
Code changes after your feedback have been pushed. Only thing remaining is the code duplication remark. Any suggestions? |
None that would be within the scope of this PR. I think a larger refactor of the If you can rebase this down into a single commit, I'll get it into master. |
Done. |
Awesome, thanks. Tweaked the commit message a little and merged in a2d9d90 |
Add Settings.bundle which contains CocoaPods 'Acknowledgements' section (updated on every
pod install
) as well as an entry containing the version & build number (updated on each build).