New Command Line Syntax

[Chris Eppstein]

I'm putting together a more user-friendly command line syntax for the next release that will also be more extensible. The current command line syntax will be supported for the foreseeable future but will probably be deprecated when compass hits 1.0.

I've put together an example of how I'm thinking the new command line syntax will look:

https://gist.github.com/82b5de6ae9cf413be199

I know it's pretty sparse on details. Many of the existing command line options like --sass-dir, --css-dir, etc will still work on the project related commands.

Note that framework/pattern is now a shortcut for what used to be -f framework -p pattern (E.g. blueprint/buttons)

I wanted to collect feedback before proceeding with implementation.

-Chris

[Alex Cabrera]

Where is "compass extensions available" going to pull from? Are we
going to have to have to set a COMPASSPATH env variable?

Likewise, what are extension developers going to have to write so
compass can provide help with "compass help extension_name"

You have a way to list extensions in a project, but there doesn't seem
to be be a way to list globally installed extensions.

I'm not crazy about the create command. It's just going to read a bit
weird (I really like readable command that tell you what they're going
to do). How about something like:

# compass create /path/to/project with blueprint

I'll post some more thoughts as they come in, but a revamped CLI is
going to be sweet.

Alex Cabrera
Interactive Director, Policus
http://policus.com

[Adam Stacoviak]

Again, "Extensions". You posted a link to this the other day: http://github.com/chriseppstein/compass/blob/edge/EXTENSIONS.markdown Did I miss something detailing the difference between Extensions and Plugins?

Is 'compass validate /path' new?

--
Adam Stacoviak | Handcrafted
m. 713-492-4598
http://twitter.com/adamstac
http://gethandcrafted.com

[Chris Eppstein]

I think extension is a better term than plugin. The code actually calls them Frameworks. It's all the same thing. Sorry if it's confusing. I'm trying to nail down the 1.0 terminology. Do you think it's bad?

Validate is not new. It's been around for a while now as "compass --validate".

chris

[Chris Eppstein]

Great questions. Answers inline.

On Wed, Sep 30, 2009 at 9:06 AM, Alex Cabrera <al...@policus.com> wrote:

Where is "compass extensions available" going to pull from? Are we
going to have to have to set a COMPASSPATH env variable?

I get that even using a command line is pushing the target users out of their comfort zone. So setting an environment variable is too much to ask, in my opinion. Compass extensions will work by simply being a folder in the correct spot. That correct spot in a project will be project_name/extensions. Global extensions will be placed into the compass folder right next to the compass and blueprint frameworks.

 

Likewise, what are extension developers going to have to write so
compass can provide help with "compass help extension_name"

A file called README.txt or README.markdown will be able to be placed at the top of an extension or in any of the template directories.

 

You have a way to list extensions in a project, but there doesn't seem
to be be a way to list globally installed extensions.

It will list both if you are in a compass project.

 

I'm not crazy about the create command. It's just going to read a bit
weird (I really like readable command that tell you what they're going
to do). How about something like:

# compass create /path/to/project with blueprint

I actually had that exact thought. it's a bit non-standard for folks who are used to CLIs.

 

I'll post some more thoughts as they come in, but a revamped CLI is
going to be sweet.

Thanks for your feedback!