Join GitHub today
Core flags given after task names fail silently #466
Thanks to #205 we can now do things like
Unfortunately, a bug snuck in (quelle horreur!), namely that other core flags given after task names seem to just...do nothing. For example,
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
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.
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...