New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mutliple invokation of the same task. #167

Closed
sophacles opened this Issue Aug 18, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@sophacles

sophacles commented Aug 18, 2014

So it seems that when I do:

inv task1 --foo=arg1 task2

everything works exactly as expected.

But when I do:

inv task1 --foo=arg1 task1 --foo=arg2 task2

I get the error:

No idea what 'arg2' is!

There is no explicit mention in the docs that I can find about repeating a task on the command line. If it has been decided to disallow this, docs should be updated. If the behavior is undefined, I vote that allowing repeated tasks is a good idea for a lot of things. For instance my uwsgi deploy code for 3 different sub-projects is a only a few command line parameters of difference. I don't like having to do multiple commands or:

inv proj1 --path=place1 proj2 --path=place2 proj3 --path=place3

when I could do:

inv proj --name=p1 --path=place1 proj --name=p2 --path=place2 proj --name=p3 --path=place3

Particularly when I add proj4 as yet another task stub function.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Aug 25, 2014

Yea this feels like a bug to me, it may be a too-naive implementation detail in the parser.

@bitprophet bitprophet added Bug labels Aug 25, 2014

@bitprophet bitprophet added this to the 0.8.3 milestone Aug 25, 2014

bitprophet added a commit that referenced this issue Aug 26, 2014

@bitprophet

This comment has been minimized.

Member

bitprophet commented Aug 26, 2014

Yea this is due to using a dict (Lexicon) in the Parser class. I think the problem is somewhere in how the parser.Contexts within that dict get mutated and handed into the ParseResult object (which is list-like, so at that point we shouldn't care about multiple 'copies' of a Context).

EDIT: Yup it was actually as easy as ensuring we copy.deepcopy when updating the parser's "current context" - which we did already do for the initial starting context (which is usually the core options) but were not doing here. Adding that one change fixes the 3 failing tests I'd added.

bitprophet added a commit that referenced this issue Aug 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment