You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The parsing functionality provided by the command and types packages currently has several major limitations that should be addressed:
Repeated flags (ex. -vvv for verbosity level) are not supported, and are currently collapsed into one.
Flags that are not at the beginning of the command are treated as generic arguments.
Flags without values are represented as BoolValue{ V: true }, which is indistinguishable from a flag with an explicit boolean value. This causes trouble for converting the flags back to arguments when calling or serializing a command.
If parseOptions.assumeOptionArguments is true, a flag with no value can steal the first positional argument. Since flags are not stored in any particular order, this makes it possible that the argument will become mixed in with other flags instead of being placed back in its old position.
--flag=value is not supported.
A command.Command currently cannot be serialized back into a string equivalent to the one it was parsed from, for many of the reasons listed above. This is worked around with command.Command.Original, but this is fragile and assigned in odd places at different levels of the system.
Command equality testing is currently not implemented.
command.Command and data.CommandEntry have a cyclical dependency, where a Command is needed to get e CommandEntry from the data access layer, but the CommandEntry then contains parse options that are used to re-parse the Command.
It would probably be advantageous to come up with design changes or a redesign that hits all of these at once.
The text was updated successfully, but these errors were encountered:
The parsing functionality provided by the
command
andtypes
packages currently has several major limitations that should be addressed:-vvv
for verbosity level) are not supported, and are currently collapsed into one.BoolValue{ V: true }
, which is indistinguishable from a flag with an explicit boolean value. This causes trouble for converting the flags back to arguments when calling or serializing a command.parseOptions.assumeOptionArguments
istrue
, a flag with no value can steal the first positional argument. Since flags are not stored in any particular order, this makes it possible that the argument will become mixed in with other flags instead of being placed back in its old position.--flag=value
is not supported.command.Command
currently cannot be serialized back into a string equivalent to the one it was parsed from, for many of the reasons listed above. This is worked around withcommand.Command.Original
, but this is fragile and assigned in odd places at different levels of the system.command.Command
anddata.CommandEntry
have a cyclical dependency, where aCommand
is needed to get eCommandEntry
from the data access layer, but theCommandEntry
then contains parse options that are used to re-parse theCommand
.It would probably be advantageous to come up with design changes or a redesign that hits all of these at once.
The text was updated successfully, but these errors were encountered: