Closed adhocore closed 6 years ago
Hmm is that a wise thing to do? How do i now pass in no args at all?
in a sub environment scenario the whole command could just be overwritten. Do we have an actual use-case for this?
no args would be something like this:
"composer": {
"command": "%action% %args%"
}
we have use case already in api for sdk generation. it can be used in other cases mainly to wrap more frequent arguments neatly like composer install --too-many-args
true, but for basic commands like composer
, npm
etc. the default behaviour is exposing the cli. Now when nothing is passed something else will happen, which might come in as surprise and basically forcing people to have a closer look at the docker-project.json even for standard commands.
This is close to a KISS violation to me, adding magic were none would be expected. In your example --prefer-dist
should come from the composer.json if it's to be set by default. And applying --no-scripts
as a default behaviour is basically the opposite of default composer behaviour.
The multi-command changes may need a fix to properly accept arguments, but i hope we can find a different approach for this. If there's a need for customized long arguments in a command for a certain project, there is already the obvious and simple solution of just adding a command for it.
Something that is unique to a project (for instance talking to a project-shellscript/CLI within the project) is perfectly doable like this already and runnable from in/out of the container. They can have some magic as they require knowledge of the project anyway. Relays to native components, especially those which are largely shared between projects and are often used natively on the developer machines as well, should feel as native as possible and shouldn't offer hidden magic if not absolutely required for actual functionality.
If we don't have this as an explicit need, then we really don't need that feature. : )
the real usecase for api is for sdk and not about composer. this feature doesnot force one to have default, but support it just in case - it is not new concept for cli to use default behaviour. so it is up to developer to decide if he needs default args for his actions. composer action may not need it (composer is not a good example here though) but most of the usage of composer here is just doing installation and very few update (rest hardly ever happens). it is unwise to alias native composer
command with such tweaks but this is just an extra ability on dopr composer
, where dopr
itself is an extra ability on top of docker and when ever we need to invoke action by suppressing default args, it is really simple: just appending hyphen like so dopr <action> -
should work fine, but again that is hardly required because we are defaulting to most used arguments and that can be skipped. as for other sets of arguments, well they can be used like before.
Fix command parsing: For the host level command, args parsing is currently skipped, need to fix this. Also make it regex replace with global flag.
Add default args An action might provide
"args"
string value that is used as fallback when interpolating%args%
from"command"
. Consider belowcomposer
action:As per this default, running
dopr composer
will actually runcomposer install --prefer-dist --no-scripts
but runningdopr composer update
will runcomposer update
in the underlying service container