Don't overwrite shared schemes

[keith]

Currently if you define schemes in your project configuration, they will be created as shared schemes. This also overwrites any existing shared schemes. The problem is that if you create a scheme in the Xcode UI, it defaults to share so if a user forgets to uncheck that when creating a custom scheme, their schemes will be overwritten the next time they generate.

I think ideally any shared schemes in XcodeGen would just be added along side any currently existing shared schemes (unless they have the same name, at which point they should be overwritten)

[yonaskolb]

Hmmm, that would make sense if adding schemes from the Xcode UI, but what if someone renamed a scheme in the spec, then the old one wouldn’t get deleted. I guess that would force scheme maintainence into the UI.
I would say if someone is adding a shared scheme they should do it in the spec, and if it’s a private one they just have to remember to uncheck shared.
Though perhaps people are hitting some limitations with schemes in the spec, and would like to create them on their own.
Maybe an option to clear or keep schemes would be best?
Thoughts?

[keith]

I think in our case people are just used to creating schemes in the UI that they don't actually want to be shared, but all the "new scheme" flow has you choose is the target, so they have to go back into edit to uncheck shared, and they forget to do so.

I think the old scheme sticking around probably isn't a huge deal, I personally occasionally delete the project entirely to clean up the old user specific ones for the same problem

[yonaskolb]

I’d be ok with not deleting the shared schemes directory if you want submit a PR. Without looking at it, there’s a large chance that logic lives in xcodeproj, so the change would probably have to be there

[yonaskolb]

As a note I've been meaning to extract the file writing logic out of xcodeproj and into XcodeGen, to give us a bit more control about how files and directories are deleted and written

[pvinis]

Why would you need a non-shared scheme, and why not put it in the yml? The whole idea here is that you generate a project with the yml, right, so it should always generate the same project (or the same structure at least). So why not put the non-shared schema in the yml or a yml as a private change/patch/include?

[keith]

The non shared schemes are not in the yml, they are the ones the users are creating. What I meant was the schemes users create aren't always applicable enough to check in to the config

[pvinis]

Could you give me an example?

[keith]

In our project we have app and static library targets. We create schemes in our config for the app targets. Since we have many static library targets we do not add schemes for them in the config since it would bloat Xcode and not everyone needs them. Occasionally developers create schemes locally for the static library target they're working on. This is the point where Xcode's UI default of creating a shared scheme is a problem.

[pvinis]

Aha. So couldn't you have these schemes in the config commented out? and when people need them, comment them in?

[keith]

In our case we have over 200 static library targets so that would be pretty unwieldy. Also one reason people create them manually is because they don't want to do a regen because that can take too long (depending on how they regen we actually create schemes for them)

…

-- Keith Smiley

On Feb 13, 2019, at 07:49, Pavlos Vinieratos ***@***.***> wrote: Aha. So couldn't you have these schemes in the config commented out? and when people need them, comment them in? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pvinis]

So more than one people generate more than like 30 schemes manually?!

[keith]

I'm just saying the commented out code in our config would have to handle many many cases because the 60 engineers can create whatever schemes they want

…

-- Keith Smiley

On Feb 13, 2019, at 07:59, Pavlos Vinieratos ***@***.***> wrote: So more than one people generate more than like 30 schemes manually?! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pvinis]

Alright, pass then. I don't think I can help here.
My initial point was that ideally, I would never want to have to delete the project to "clean up", but I see your use case is an interesting problem.
I'm sure a solution can be found that will help your case too :)