Add Podspec

[MaxGabriel]

In progress Podspec per #29.

Everything should be working -- it's just testing and cleaning out unused files at this point.

For things like the summary in the Podspec, I just copied from existing Subliminal materials without making an attempt to change things.

[wearhere]

When people search Cocoapods, do they see both the summary and the description? (My cursory searches of Cocoapods only reveal summaries, but it's possible that the result pods' specs only specify summaries. If only Cocoapods linked from results to specs--or more specs were maintained by the projects themselves...)

If someone browsing Cocoapods will see the description too, I might prefer having the summary be Subliminal's tagline ("An understated approach to iOS integration testing").

[MaxGabriel]

The only sites I've searched for Cocoapods on are CocoaControls, Cocoapods.org, and Cocoadocs.org, all of which just list summaries. I'll switch it to your tagline since it's fun

[wearhere]

Thanks for putting up the podspec @MaxGabriel, I'm pretty excited to get this in place.

I still have to review your documentation but I'm waiting to have the podspec all up-to-date before getting into that. I will say that I think having it as a wiki is a good idea though. I think that the README should contain 1) an overview of the framework and 2) info which you might need to have locally and I doubt that detailed installation instructions meet either of those criteria.

[wearhere]

Linking to Subliminal's docs either on Cocoadocs or on GitHub (http://inkling.github.io/Subliminal/Documentation/) is a great idea.

I'd also like to have Cocoapods auto-generate Subliminal's documentation like this suggests. Cocoapods should use the command used by the "Subliminal Documentation" target's run script build phase.

[MaxGabriel]

I don't know if this has been announced online but at the WWDC cocoapods meetup they said they were deprecating this feature and just relying on Cocoadocs.org instead.

[wearhere]

They're deprecating local installation? That's a shame--it's much nicer to see docs locally than online, especially with Xcode's quick help--but that's ok, I can add a task to the Rakefile to do that if Cocoapods won't. Does Cocoapods still let you customize how the documentation is generated though?

[MaxGabriel]

I think Cocoapods lets you customize the documentation settings, but Cocoadocs doesn't. Advantage to just using Cocoadocs is that Cocoapods will name the documentation set by version number so you end up with hundreds of doc sets over time. Cocoadocs lets you download straight to Xcode, though (top right corner).

will get back to you on more of this stuff after work.

[MaxGabriel]

Oh actually it was removed in .20 (Ctrl+f "Graduated")

Your rakefile handles generating documentation anyway, so it should be ok.

[MaxGabriel]

Do you think it'd be a good idea to do the rake install step as a post install hook?

[wearhere]

Yeah, I think the post-install hook is a good place to install the supporting files. And I guess we should not install the docs there (rake install DOCS=no) 'cause the user can't pass options to pod install, and because it's convention to put the docs on Cocoadocs.

[wearhere]

@MaxGabriel good eye re: the platform, but I've found a solution to http://openradar.appspot.com/radar?id=3107401, so Subliminal will have full support for 5.0 today or tomorrow. :D

My plan for this week is:

• Bring Aegolden/ios5 compat #11 in.
• Update the documentation for the new install instructions and some other miscellanea.
• Bring this in.
• Tag 1.0.2 and update the spec.
• Publicize 1.0.2, including Subliminal's new support for Cocoapods.

[MaxGabriel]

Ok I added the rake install DOCS=no as a post_install hook. I think because Cocoapods has Rake as a dependency so that'll definitely be available (?).

It feels a little weird that it uninstalls and reinstalls every time I update a Cocoapod, but it works perfectly every time, so it should be ok for now.

[MaxGabriel]

OK I think this is ready to merge in. Is it missing anything?

Here are the proposed docs.
A project to test installation with Cocoapods is here.

[wearhere]

Hey @MaxGabriel, thanks for readying the branch. Now that #11's gone in, you can update the deployment target (s.platform) to 5.0.

I'm going to update the docs tomorrow to simplify the installation process and prepare to incorporate the Cocoadocs setup. At that time, I'll ask you to remove the INFOPLIST_FILE and PRODUCT_NAME settings, and then merge this request.

[mclark4386]

any word on this? It would make my life easier^^
Happy to help in any way I can, but it just kinda dropped off 21 days ago so don't really know what's where to help^^;

[HaloZero]

So I'm curious since this has been inactive for a month, any plans for podfile integration? I've had massive trouble integrating sublime into an already podfiled app and it would be nice to have this.

[tulushev]

Another 3 month passed. Any movement?

[dornad]

Hi. Has there been any movement in here? I'd love to add Subliminal to my PodSpec file!

[lisbakke]

Ping. Anything on this?

[MaxGabriel]

I've made a couple of updates to the Podspec since it was initially introduced.

1. Updated the source_files attribute to add the Logging directory
2. Added the documentation_url and social_media_url attributes.
3. Removed the post-install hook to install the file templates. I've been happily using my branch to install Subliminal via cocoapods for some time, and each time I felt a little uneasy about the reinstallation of the templates. It feels out of place, especially because it runs when you install a different Cocoapod.

Edit: Man, as soon as I install Subliminal without having the post-install hook I felt weird about that too. Its easier on CI to have it installed via the post-install hook. I could go either way on that...

You can try this branch with the following Podfile syntax:

target :'Integration Tests' do
  pod 'Subliminal', :git => 'https://github.com/MaxGabriel/Subliminal.git', :branch => 'cleanCocoapod'
end

The documentation for installing with Cocoapods is on this wiki. If this PR is merged I'll just add a new page to the (currently empty) Subliminal wiki and copy over what's in my wiki.

I think this is ready to merge—is there anything left to be done?

Edit: I saw that SLLogger is now also part of its own OS X framework. I'm not sure what's up with that—I've basically just ignored that for the Cocoapod.

Edit: I've tested this branch with the project my company uses. The Subliminal tests pass on Travis CI.

[MaxGabriel]

Re: The Travis test failure. It failed on just 1 test of the matrix (the iOS 7.0 Integration Tests). That's just a false positive I assume? https://travis-ci.org/inkling/Subliminal/builds/21061766

[lisbakke]

Thanks a ton, @MaxGabriel, this PR and your wiki worked great for me.

[MaxGabriel]

@lisbakke How do you feel about installing the Subliminal Instruments template via the Cocoapods prepare_command hook? (s.prepare_command = 'rake install DOCS=no')

[lisbakke]

@MaxGabriel I thought it was fine. When I had my coworker pod install and then show him how to run the tests, it slipped my mind for a moment that I had to have him run that. However, it's easy enough to do.

I installed subliminal both via the normal wiki, and via this PR. When I had my coworker just pod install it, it was so painless. I really hope this gets merged, because it's a major improvement. Also, I think a lot of ios devs use cocoapods these days..

[MaxGabriel]

@lisbakke I actually had the same experience showing another dev how to install the templates the other day. I added back the installation via the prepare_command hook in the Podfile.

@wearhere I think this is ready to merge—do you need me to make any changes to accept this PR?

Edit: If this is merged, the repo will just need to be tagged with whatever the current version is, the Podspec updated with that version number, and the pod spec submitted to Cocoapods.

[MaxGabriel]

Now that #145 has been merged I plan on removing the INFOPLIST_FILE and PRODUCT_NAME build settings from the xcconfig values that the Podspec provides, and updating the wiki to remove those parts. This will make the installation instructions much slimmer and allow you to keep the plist file of your integration tests in sync with your main target.

(If you're using my branch as the Cocoapod source, this will be a breaking change, but should be quite painless as you'll just need to reselect the info-plist file and give your target a product name).

I'll also move the image used in the documentation to the gh-pages branch with the rest of the images.

[wearhere]

Hey @MaxGabriel, thanks for updating the Podspec. Here is I think the definitive list of things left to do, and then I will merge this:

• Change the deployment target to 5.1--I was mistaken earlier in saying that it was 5.0 (Fix the deployment targets in the README. #151).
• Remove the INFOPLIST_FILE and PRODUCT_NAME settings from the Cocoapod and the wiki.
• Remove the note about running rake install from the wiki, since the pod will do it. (I agree that it's nicer to have the pod do it, though it is a bit weird to have multiple installations reinstall the supporting files: Officially support multiple installations of Subliminal. #152.)
• Move the image to the gh-pages branch.

I'd love to take you up on your offer (#82) to move the regular installation instructions to the wiki at this time as well, so the installation process is mostly unified, looking like this:

    create the Integration Tests target
    /                                   \
install into target manually    install into target using Cocoapods
    \                                   /
       add test-running code to target

Thanks so much for your patience.

P.S. Don't mind the SLLogger framework--that's used only by subliminal-instrument's unit tests.

[MaxGabriel]

Awesome, sounds good.

• Change deployment target to 5.1
• Remove INFOPLIST_FILE and PRODUCT_NAME
• Remove rake install step from wiki
• Update wiki to fit in with new regular wiki
• Move image to gh-pages branch
  • (The image isn't needed anymore b/c the wiki will be just the Cocoapods part, so its removed)
• Rebase this branch
• Add wiki page to Subliminal wiki
  • Will just not link to it from the main page/guides until this is merged

[MaxGabriel]

Ok this is all ready if the tests pass. Once the new README is merged, then this can be merged, then I'll update the wiki in a couple of spots to link to the Install with Cocoapods page.

edit: I guess once this is merged, the repo should be tagged as 1.0.2 and the podspec updated?

[wearhere]

Cocoapod and docs look good! I made two changes to the docs, one to remove the note about pod install installing Subliminal's file templates--since the user doesn’t know (nor need to know, I think) about them when they execute the command; and the other about inhibiting warnings in the Subliminal repo. I'd rather not encourage that 'cause it looks like we're trying to hide something imo and honestly we shouldn't have any warnings to hide (not after #165 at least ;).

I think we should do 1.1 actually--there've been a ton of new features and bug fixes since 1.0.1. (I would do 2.0 even if not for that I'd like to do actually adopt semver going forward ;)

I'm going to go ahead and merge this now. You can go ahead and update the wiki too though I'm not going to call 1.1 just yet--before a bunch of new people see the repo, I want to add contributing guidelines (#166) and a honest-to-god changelog (#167), haha. Big changes!

[wearhere]

Btw, everyone following this discussion: I'm not going to tweet about the Cocoapod from @subliminaltest until I call 1.1 (remaining issues: #166 and #167, no later than the end of the weekend--I'm on vacation currently ;) to give new users the best impression. Rest assured though, I will trumpet this. Equal and immense apologies for the delay and thanks to @MaxGabriel!

[MaxGabriel]

Cool thanks for the merge @wearhere

Re: inhibiting warnings, that was actually about #164. If the integrator says their project's deployment target is e.g. iOS 7 in the Podfile, then they'll those warnings

[wearhere]

Ohh I see @MaxGabriel. I still think I'd rather leave warnings on so that if/when they arise users can come to the repo and file an issue or see that we're working on it (and if necessary, be informed that they can inhibit warnings in the meantime), rather than just hide them off the bat.

[lisbakke]

Awesome! Thanks a lot for doing this, @MaxGabriel

[MaxGabriel]

No problem @lisbakke, but just continue using my branch until Subliminal gets a new tag (1.1) and is submitted to the Cocoapods Specs repo.

Edit: actually that's not the right move, instead of my branch use master of inkling/subliminal: :git => 'https://github.com/inkling/Subliminal.git'