Swift

[gfontenot]

This adds support for generating Swift projects.

Yeah, I know, finally.

[gfontenot]

Note that this introduces a slight breaking change if users have been overriding the application_target_groups or unit_test_target_groups keys in their own liftoffrc

[tonyd256]

how come have this for swift but not objc?

[gfontenot]

I want to do another pass to standardize the Obj-C structure based on this newer structure. That's out of scope for this PR though.

[rokob]

[gfontenot]

@thoughtbot/ios Any feedback on this? Especially looking for feedback on the UI and directory structure.

[keith]

👍 on this directory structure.

[hyperspacemark]

So swift is the default and using --no-swift forces it to use objective c? That seems just a little weird because it's not really an option but a binary choice that is fundamental.

[hyperspacemark]

Should add that I don't know what the ideal interface for this would be.

[keith]

Maybe the opposite should be --objc

[gfontenot]

I didn't want to do --objc because that introduces a weird state where you could theoretically pass --swift and --objc at the same time, and the outcome would be totally determined by the order that you pass the flags. Given that it actually is a binary choice (we don't support other languages), using a boolean flag made more sense to me.

That being said, I was thinking about this on my way home yesterday, and there's a chance we could make the entire thing more flexible by using top level dictionaries for the language name, and then using a --language= flag on the command line to choose. This could also be used to create non-language specific project templates. For example, given this structure:

app_target_groups:
  empty:
    - <%= project_name %>:

you could theoretically pass --template=empty to the executable, and have liftoff use the proper structure. That would change the entire concept of language to template, but that's probably closer to what we're doing anyway.

The issue here would be that (when implemented the simplest way possible) overriding the app_target_groups key would mean having to reproduce all of the other templates. Ideally, we would use some sort of Programming Magic to make that key (and the unit test target groups) stackable. So if you added an empty template to the app target, you'd still get our objc and swift templates for free.

I think I've totally talked myself into this idea. Good job, me.

[gfontenot]

I just pushed a WIP update (it works, just doesn't have all of the features) that changes the format used to be more generic, and hopefully more flexible.

[gfontenot]

Ok, I think this is all set for final review. I'd also appreciate some eyes on the man pages (view in a gist here). Especially the TEMPLATE DIRECTORY STRUCTURE section. Let me know if anything isn't clear.

[tonyd256]

should this be single hyphen -template ?

[tonyd256]

👍 just confused on if there should be a single or double hyphen in front of template

[gfontenot]

It should be a double hyphen. If you look at the rendered version (above), you'll see that it's consistent.

[mike-burns]

How about Hash#merge instead? Maybe something like:

def evaluated_configuration
  initial_configuration.merge(template_groups_configuration)
end

def initial_configuration
  default_configuration
    .merge(user_configuration)
    .merge(local_configuration)
    .merge(@options)
end

def template_groups_configuration
  TEMPLATE_GROUPS.inject({}) do |acc, key|
    acc.merge(key => evaluated_templates(key))
  end
end

[mike-burns]

Oh, or just add another #merge to the end of #evaluated_configuration. Either way: #template_groups_configuration could be broken out.

[gfontenot]

Oh, yeah, good call. I like that a lot.