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
Core flags given after task names fail silently #466
Comments
Figured this out just now while poking a related issue; it's simply because the code added for #205 did so in a very backwards compatible fashion (added The rest of the core arg attending code (i.e. that which sets things like Have a fix in place and as usual updating the tests is gonna take a bunch more time than the fix itself 😓 |
Also, wondering if this is truly a bug or an expectations mismatch:
|
The docs appear very specific that this behavior was intended to be for Of course, given it's easily fixable, I still think I'd like to do so, I just gotta tidy up that test suite and enhance the docs. OTOH, my spidey-sense is tingling; this feature has always had the issue of what to do when ambiguity strikes (if a task has a But even given this, the problem is one of consistency: as soon as the user encounters one of those "ambiguous, but the task wins" scenarios, something that used to work (or works on other tasks) stops working. E.g. say everybody gets used to slapping " I don't see any solution to that, and so my worry is that if I make "all core args are valid for all unambiguous contexts" a real thing, that inconsistency problem will become more of an issue for the average user. Or I can take the door that's open to me here, and say that this is actually the opposite bug, calling A counter-counter-argument is: I ended up back here because I wanted to see if it was feasible to implement If we do go that direction, there is another issue: the implementation of #205 left us with an annoyance in the parser code, where it says "if we're in a task context, and we see a core flag and it takes a value, use the context name as the value instead of looking to the next token". This is why But it means any other core flag taking a value doesn't work anymore in a task context! E.g. If this is to be fixed, it needs some other way of marking |
I suppose another way to look at the "you can slap Another argument is simply that there's no putting the There's no clear-cut winning here, so I am thinking we might as well roll with the convenience, as much as it pains the purity-minded side of me. |
Diving into this and mostly done, I find that yanno...the split between Given that this parser-exposed behavior was not even possible beforehand, and we're technically changing behavior (albeit from EDIT: grumble, while there was no attribute-docstring for |
Went halfsies and decided to make this overall a feature-level-bugfix; this way it limits patch level stability issues. Seem to have actually sorted out behavior & tests (including a potential roadblock in the parser, which was fixed via some |
Ran into some extremely stupid sidequests and still not done with them. The main issue consists of the pseudo-internal APIs in Program and Executor; needed a way to easily represent the union of the "true" core flags (as parsed at the front of the CLI) and the "via tasks" core flags (the new behavior added here). Initially decided not to modify Got that all working, only to find out that, oh. This works fine for core Invoke, but for downstream code like Fabric, which does work in a custom Executor that wants access to core flags (specifically in this case, a The problem: the new shiny I'm glad I'm rubber ducking this because I think the solution might actually be easy. I was hesitating to go the obvious route - mutate Then I remembered, well, older versions are arguably broken as-is - users can give the core args after tasks, and nothing happens (or, in even older versions - IIRC pre-1.0 - an explosion occurs because those flags are invalid in that position). Going from a silent error to the data becoming updated isn't a problem. It'd only be a problem if there had been a prior release where this functionality already worked and was implemented in a way that left Still means I have to shuffle all the new code and tests I wrote today, but, whatever. Wasted so much damn time on this as it is... |
…flag parsing Should wrap up #466, still awaiting final real world tests
OK, that's a wrap. Both Invoke and Fabric 2 can give core flags anywhere they like. |
Thanks to #205 we can now do things like
inv mytask --help
to get per-task help.Unfortunately, a bug snuck in (quelle horreur!), namely that other core flags given after task names seem to just...do nothing. For example,
inv --echo mytask
shows command echoing, butinv mytask --echo
does not. No error, but also no echo.At first I feared this meant that any post-task flags that were invalid were getting swallowed silently, but this doesn't seem to be the case, things like
inv mytask --lolno
still result in parser errors.So I think this is probably just a TODO that isn't implemented yet, where we need to add more logic/behavior interpreting the rest of the core flags on a per-task-execution basis.
The text was updated successfully, but these errors were encountered: