Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Core flags after a task name are silently consumed as positional values (same root cause as #982, beyond --help)

Open
#1,084 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
cli

Research direction

Start in Parser.handle, using the reproductions for build --echo, --dry, --debug, and --warn-only as the baseline. Compare the existing --help handling from #1078 with the positional-argument branch. Done means each core flag takes effect after a task name instead of being consumed as the target value, including preventing real execution for --dry.

Written by the indexing model from the issue text.

Description

#982 / #1078 fixed this for --help, but the same defect applies to every other core flag when given after a task name whose positional arguments are not yet filled: the flag is silently consumed as the positional value and the task runs instead of the flag taking effect.

Version: invoke 3.0.3 (release) and current master. Python 3.13, Windows.

Repro

# tasks.py
from invoke import task

@task
def build(ctx, target):
    print(f"BUILDING {target}")
$ invoke build --echo
BUILDING --echo          # task RAN; echo mode not enabled

$ invoke build --dry
BUILDING --dry           # "dry run" executed for real

$ invoke build --debug
BUILDING --debug

$ invoke build --warn-only
BUILDING --warn-only

All four core flags are swallowed as the value of the still-unfilled target positional. Same happens on current master (verified). The --help case was fixed in #1078 by checking it before the positional branch; that PR's commentary explicitly scoped everything else out ("Unlike other initial-context flags..."), but the remaining flags have exactly the same never-a-valid-positional property — no task legitimately wants the literal string --echo as data.

Why this is worse than it looks

--dry being swallowed means a user who believes they are doing a dry run actually executes destructive tasks against real targets. That's a safety-relevant failure mode, not just an inconvenience.

Proposed direction

Generalize the #1078 approach: before the positional-arg branch in Parser.handle, treat any token matching an initial-context core flag as that flag (setting its value / entering flag state), regardless of pending positionals. If backwards compatibility concerns exist for tasks that genuinely accept e.g. --echo as a task-level flag — note those are matched per-context later anyway, so initial-context handling can stay reserved for core flags.

Happy to send a PR generalizing #1078's fix if maintainers agree on the semantics.

Dominant language
Python
Stars
4.8k
Forks
412
PR merge metrics
No merged PRs in 30d

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pyinvoke/invoke

All issues in pyinvoke/invoke

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.