Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

User specified configurations -or- custom commands #35

Closed
Ashton-W opened this Issue Mar 31, 2013 · 5 comments

Comments

Projects
None yet
2 participants

I would like to start a discussion on how user customisations of liftoff could be implemented.


My idea would be a ruby script that can be specified on the command line that would contain user settings and scripts to run, using helper methods from liftoff to do all the heavy lifting.
Basically the user script would be similar to a Podfile from CocoaPods, technically Ruby but very simple.

I am not a Ruby programmer so I don't trust myself to implement this cleanly, but I am poking around the source code to explore what is possible.

Collaborator

gfontenot commented Apr 1, 2013

I'm worried about the overhead this would add to the setup process. What kind of things would you want to specify in the config file?

Ashton-W commented Apr 2, 2013

It would be completely optional so plain old liftoff would be unchanged.

The config file would contain build settings like the ones hardcoded into liftoff, it is basically a way to avoid having to fork the whole project to roll your own suite of project settings.

Collaborator

gfontenot commented Apr 3, 2013

Do you have an idea of what kinds of things you would want to change? Most of the commands don't seem like they would require settings. The only 3 that might make use of this would be indentation (which is already configurable), turning on specific warnings, and the git files. Adding custom git content to a config file doesn't make a whole lot of sense. And customizing the warnings that get turned on would be super tedious in my opinion. It also seems incredibly error prone.

Sorry for replying late.

The idea is to avoid having to fork liftoff to customise it. Certain organisations may have different warning configurations and build phases that what has been decided for liftoff. Forking the project is more error prone that having a mechanism to configure commands with a DSL.

I understand that liftoff is opinionated, I'd just like a nice way to add more.

I also understand it expands the scope of the project, but I believe making the commands more flexible will improve the design.

Maybe this is better implemented in a separate fork of liftoff.

Collaborator

gfontenot commented Dec 4, 2013

I don't think this is something we're going to do at this time, so I'm going to close this issue. Thanks for the feedback!

@gfontenot gfontenot closed this Dec 4, 2013

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