Find a way to hide all the Pod Schemes #1185

Closed
kcharwood opened this Issue Jul 5, 2013 · 15 comments

Comments

Projects
None yet
8 participants

I have a project that now has 68 additional schemes in my Xcode scheme dropdown since CocoaPods now builds a single target for each library. I have several nested project targets in my Podfile, so it get's pretty noisy when AFNetworking is included in 4 different project targets (since CocoaPods builds a new target for each project target).

I'd like to find a way to auto hide all these schemes in my dropdown menu. It might require a script that goes through my .xcuserdata folder and mucks with the settings there to auto hide them...

Any other ideas?

Owner

alloy commented Jul 5, 2013

I have no existing ideas. Please do experiment and find out what we would have to generate to make this work automatically after generating Pods.xcodeproj.

I have the same issue and was rather surprised by the change when I updated Cocoapods to 0.22.1 on Friday. I'm not sure I understand the motivation for adding each pod in a separate Xcode scheme. Is there a discussion somewhere that details the benefits that the cocoapods development team is after with this change?

Owner

fabiopelosin commented Jul 6, 2013

The discussion is scattered across issues, the main benefits are:
​- Clean environment to build the Pods, not polluted by the build settings of the other Pods of the target.

​- Pave the way to support different Pods based based on the build settings.

Note that we were after building Pods in dedicated targets. The separate schemes are a side effect which could be fixed by making shared schemes in CP and hiding those of the Pods. 


Sent from my iPhone

On Fri, Jul 5, 2013 at 6:50 PM, Bennett Smith notifications@github.com
wrote:

I have the same issue and was rather surprised by the change when I updated Cocoapods to 0.22.1 on Friday. I'm not sure I understand the motivation for adding each pod in a separate Xcode scheme. Is there a discussion somewhere that details the benefits that the cocoapods development team is after with this change?

Reply to this email directly or view it on GitHub:
#1185 (comment)

The Show value for shared schemes does not appear to get saved for other users.

Kevin Harwood


Sent from my iPhone

On Jul 6, 2013, at 4:34 AM, Fabio Pelosin notifications@github.com wrote:

The discussion is scattered across issues, the main benefits are:
​- Clean environment to build the Pods, not polluted by the build settings of the other Pods of the target.

​- Pave the way to support different Pods based based on the build settings.

Note that we were after building Pods in dedicated targets. The separate schemes are a side effect which could be fixed by making shared schemes in CP and hiding those of the Pods.


Sent from my iPhone

On Fri, Jul 5, 2013 at 6:50 PM, Bennett Smith notifications@github.com
wrote:

I have the same issue and was rather surprised by the change when I updated Cocoapods to 0.22.1 on Friday. I'm not sure I understand the motivation for adding each pod in a separate Xcode scheme. Is there a discussion somewhere that details the benefits that the cocoapods development team is after with this change?

Reply to this email directly or view it on GitHub:
#1185 (comment)

Reply to this email directly or view it on GitHub.

Owner

alloy commented Jul 8, 2013

The Show value for shared schemes does not appear to get saved for other users.

@kcharwood I’ll file a radar tonight to request that, we can’t be the only ones that would find it annoying to have to re-apply that setting every time.

Owner

alloy commented Jul 8, 2013

Is there any reason that the schemes shouldn't be shared?

@tonyarnold I fail to see the relevancy in this context, can you elaborate on why you ask?

No, carry on.

kejinlu commented Jul 9, 2013

Mentioned this problem before. It's too noisy when you have many pods.

One solution is to not create the schemes in the first place. After you create your project go to Product -> Scheme -> Manage Schemes and deselect "Autocreate schemes". The targets that cocoapods now adds on install will not have a scheme generated for them. When you do need a scheme for a new target, it takes 5 mouse clicks to do it manually. If you already have a ton of schemes, you can shift+select them in the scheme manager and press the "-" button to get rid of them.

Owner

alloy commented Jul 18, 2013

@almasmith Brilliant, no idea why I didn’t try that before. Thanks!

@kcharwood With this suggestion, do we really need more code in CocoaPods for this?

@almasmith that's a creative solution.

Looking at the diff when I change that property, the shared workspace settings file (WORKSPACENAME.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings) gets created/modified. That file has the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded</key>
    <false/>
</dict>
</plist>

What if before every pod update/install you do the following:

  • Check for that file
  • If it doesnt exist, create it.
  • Cache the current value of IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded
  • Set IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to false.
  • Run update/install
  • Restore the cached value

I imagine it wouldn't be that difficult using plistbuddy.

Also, this value must be stored in the workspace settings, not the project settings, so if you don't have workspace when running pod install, you wont get this behavior. If Cocoapods handled this as part of the workspace creation process, then users will get that behavior for free.

My flight attendent is making me put my computer up now! Be back later with more comments.

Actually, I'm not sure that would work. If a user clones the project into a new local folder with IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded set to True, then I think it will populate all of the schemes. We need IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to be set the shared settings to ensure it doesn't get populated.

With that said, perhaps Cocoapods can by default set IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded to be false whenever a workspace is created using pod install?

@jzapater jzapater pushed a commit to jzapater/CocoaPods that referenced this issue Sep 17, 2013

@keith keith Merge pull request #1185 from ohdonpiano/master
Added Spec NanoStore 2.6.4
4ef8b11
Contributor

xslim commented Sep 23, 2013

In addition, would be ice that Cocoapods on first install will change the current schemes to "shared schemes". So other contributors to a project will have same structure

Owner

fabiopelosin commented Sep 23, 2013

Another possible strategy could be to disable the show flag of the schemes. Currently we don't create the schemes and let Xcode to handle them, however the support for doing so is already present in Xcodeproj.

Owner

fabiopelosin commented Oct 7, 2013

Closed by cade447

alloy closed this Oct 7, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment