Command line interface

[sheerun]

This is meta-issue regarding CLI interface.

We agreed to not use rake, but dedicated CLI. I list below overview of commands that are expected to be implemented. Each command will have its own issue with details.

bowered init

• creates blank-slate Bowerfile with nice comments for explanation.

  bowered install

• behaves just like bowered update if no Bowerfile.lock is present
• creates Bowerfile.lock and installs dependencies to ./tmp/bowered elsewhere

  bowered update

• uses Bowerfile, and bower to create Bowerfile.lock
• downloads and compile assets from Bowerfile.lock to ./tmp/bowered

  bowered update [name] ...

• uses Bowerfile, Bowerfile.lock, and bower to create update Bowerfile.lock
• downloads and compiles assets from Bowerfile.lock to ./tmp/bowered

I like how bundler uses one file per command in cli directory. We can do it too.

I also like how bower uses templates to handle output of cli commands. I think our CLI commands should return streams of Hash messages and formatter should handle those.

We should try to consume JSON output from bower and display re-formatted to user.

Other possible commands / flags:

• bowered clean - removes what was installed in tmp
• bowered install --watch - watches for changes in components and re-compiles
• bowered install --offline - passes offline flag to bower
• bowered install --jobs - downloads/compiles packages in parallel
• bowered vendor [name] - downloads given component to vendor directory

Questions:

1. What library should we use for CLI?
2. What should be the output of commands?

[SergeyKishenin]

behaves just like bowered update if no Bowerfile.lock is present... ...uses Bowerfile, and bower to create Bowerfile.lock bowered install --offline - passes offline flag to bower

Could you please explain how are we going to use bower (its depth of embedding). Should it be optional like an alternative way to our own installator? We gonna use bower to make single-asset updates, okay. Are we going to use it for installation and global update?

I'm not sure that we need to have a separate --watch flag. It should be the thing that should just work by default as described in #7 (as a hook to the rails s): we are to listen to the changes all the time and recompile or not.

--jobs — cool. Maybe we should name it --threaded or --parallelize it to be more clear?

I've never written a CLI in Ruby but I guess OptionParser is pretty enough for us to parse options . Having commands described in separate files is a good idea for me.

Yes, streaming data in a easy-to-parse format is correct. Formatter for prettifying — great.

[sheerun]

I think at least for 1.0 we should use bower to generate Bowerfile.lock, i.e. resolve dependency tree to exact versions. After generating Bowerfile.lock we can download and process assets defined there without using bower.

The main idea is to make bowered independent of rails, so we can't use rails s. On the other hand we can hook install --watch to rails s if Rails is available (or more generally for rack apps).

--jobs flag is already used by bundler and make, so I think users will be more familiar with it than --threaded or --parallelize.

[SergeyKishenin]

I think at least for 1.0 we should use bower to generate Bowerfile.lock, i.e. resolve dependency tree >to exact versions. After generating Bowerfile.lock we can download and process assets defined >there without using bower.

Okay!

or more generally for rack apps

Yes, it should be some kind of callback for Rack::Server#start class method.

--jobs flag is already used by bundler and make, so I think users will be more familiar with it than -->threaded or --parallelize

Never heard about Bundler's --jobs flag. Let's have it then!