wplib / box-scripts

Scripts for WPLib Box
Other
2 stars 4 forks source link

Add args for commands #5

Open clubdeuce opened 8 years ago

clubdeuce commented 8 years ago

For example:

box import_db filename

would be much easier to implement with the API (and allow for future extensibility) if it looked like this:

box import_db --importfile filename

Can we make that happen?

mikeschinkel commented 8 years ago

@clubdeuce I fear if I focusing on the CLI framework at first I will get bogged down in architecting and not actual implement the functionality that is higher priority short term. So short term I would prefer not to focus on the CLI framework but instead implement more functionality, especially because we have a lot of functionality to implement.

But what about short term for the API?

I have been assuming you would handle it much like how WordPress handles API routing and that being with an array of match patterns as keys and result patterns as values. For example (something like):

$commands = array(
    'GET:/db/import/{filename}' => 'box import_db {filename}',
    'POST:/projects/new' => 'box project new {project}',
    ...
);

Then later if we evolve the CLI commands we'd only need to change it like so:

$commands = array(
    'GET:/db/import/{filename}' => 'box import_db --importfile {filename}',
    'POST:/projects/new' => 'box project new --project {project}',
    ...
);

Will something like this not work?

clubdeuce commented 8 years ago

@mikeschinkel Yes, your assumption regarding the implementation of the API is essentially correct. And, yes, it does work.

That being said, I do not understand your response. This issue is that of using positional arguments versus named arguments. My intention for opening this issue was to refactor existing commands to use, and implement all future commands using, arguments that are named as opposed to positional.

I view this as analogous to method signatures. Using named arguments will allow us to not have to go back and change the API processing if the command changes. We would only need to update the route to accommodate new parameters.

Not being well versed in BASH, I am not sure how easy this is to implement.

mikeschinkel commented 8 years ago

"My intention for opening this issue was to refactor existing commands to use, and implement all future commands using, arguments that are named as opposed to positional."

@clubdeuce So I completely agree with you in concept and also long term. Short term I am hoping to avoid implementing a proper CLI framework, at least for a while.

"Not being well versed in BASH, I am not sure how easy this is to implement."

Therein lies the rub. When I previously looked at how to do a robust CLI I did not find a good consensus on how best to implement a Bash CLI framework. Every example I looked at was significantly different, and significantly complex.

What I would like to do is build out the functionality of the commands we need and once we get to parity with VVV+VV and Pressmatic then go back and refactor the commands to use a CLI framework, which I may have to architect and build too. And the more experience I have writing Bash the easier it will be to decided on an implement a proper CLI framework.

Is it possible for use to share maintenance of the API/Command mapping file in the short term?

clubdeuce commented 8 years ago

@mikeschinkel See my commit against this issue above.