I always lacked this (small) feature myself, but since I'm not the only one, I'd suppose to add it. Closes #297.
It is the most conservative solution: when no ipkg argument is given, it searches for the only available ipkg in the current directory and complains when was unable to find one or when there are too many of them.
It does not search in the upper directories when there is not ipkgs in the current one, and does not interact with any local pack.toml files during the search.
In case of additional arguments in the run command, since Arg parser for Maybe is greedy, we use this property to preserve the status quo behaviour: when anything is given after pack run, it is interpreted as the package name or package file. We are not trying to guess whether or not the first argument is a file or a program's parameter (and I think, it would be silly to do so, since program's argument can be a file anyway).
I always lacked this (small) feature myself, but since I'm not the only one, I'd suppose to add it. Closes #297.
It is the most conservative solution: when no
ipkg
argument is given, it searches for the only availableipkg
in the current directory and complains when was unable to find one or when there are too many of them.It does not search in the upper directories when there is not
ipkg
s in the current one, and does not interact with any localpack.toml
files during the search.In case of additional arguments in the
run
command, sinceArg
parser forMaybe
is greedy, we use this property to preserve the status quo behaviour: when anything is given afterpack run
, it is interpreted as the package name or package file. We are not trying to guess whether or not the first argument is a file or a program's parameter (and I think, it would be silly to do so, since program's argument can be a file anyway).