google / google/python-fire

Ignoring convention that `--` separate non-flag arguments in bash (apart from last `--` for fire flags)

Abierto
#580 2 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Python
Estrellas
28.2k
Forks
1.5k
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

Beyond the fact that fire uses the last `--` to separate flag argument from command arguments, it seems that previous `--` are not parsed correctly. At least according to the common convention that a double dash ( -- ) is used in most Bash built-in commands and many other commands to signify the end of command options, after which only positional ("non-option") arguments are accepted ([source](https://unix.stackexchange.com/a/11382)).

I would like to use this to pass some other commands to a fire command, without the flags targeted to the extra command being parsed by fire. Here is a minimal example `test.py`:

```python
import fire

def foo(*args: str, flag: int = 2) -> None:
print(f"{args=} {flag=}")

fire.Fire(foo)
```

Current behavior:
```bash
$ python test.py -- other args 1 2 --flag 3 --
args=('args', 1, 2) flag=3
ERROR: Could not consume arg: --
Usage: test.py -- other args 1 2 -

For detailed information on this command, run:
test.py -- other args 1 2 - --help
```

Expected behavior:
```bash
python test.py -- other args 1 2 --flag 3 --
args=('args', 1, 2, "--flag", 3) flag=2
```

Would you be fine with updating the parsing rules in https://github.com/google/python-fire/blob/6cf45c663075c96b20dd0dfa733c2374545a4ad6/fire/core.py#L376 to consider all remaining args as positional arguments if it encounter a `--` ? I could work on a PR if there is no major blocker.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.