poetry: `poetry run` regression for handling command flags

Commit 85dc9a1 should fix most of the issues with the run command.

I will try to make a new beta release this week.

If you upgrade to 1.0.0b3, you need to use -- to stop options parsing now it looks like.

See this change in the clikit dependency which poetry uses: https://github.com/sdispater/clikit/pull/2

Edit: you shouldn’t need this anymore with the latest 1.0.0b4 release it looks like. That release is more in line with https://github.com/sdispater/poetry/issues/1500#issuecomment-547608347

@sdispater Has this been resolved? I’m still getting an issue when I run poetry -v run pytest --record-mode=none The same thing is wrong in when run in tox 😦 I’m on Poetry version 1.0.10

Could this be reopened? It seems to have regressed again - I’m using Poetry version 1.1.11

When any poetry options are included for poetry run, the parser consumes all options, making it impossible to pass options to the target command.

poetry run with no options works as expected:

$ poetry run python -c "print('Hello from Python!')"
Skipping virtualenv creation, as specified in config file.
Hello from Python!

But, giving an option, (e.g. to switch off the warning about virtualenv creation), and all options are consumed, causing an error:

$ poetry --quiet run python -c "print('Hello from Python!')"
<stack trace omitted>
NoSuchOptionException

The "-c" option does not exist.

This gets even funkier when poetry does support the option that was intended for the target command; poetry acts on that option, instead of passing it through:

$ poetry run python -V                              
Python 3.7.10
$ poetry --ansi run python -V
Poetry version 1.1.11

The suggested workaround of using a bare -- does not work either:

$ poetry --ansi run -- python -V
USAGE
  poetry help [<command1>] ... [<commandN>]
...
$ poetry --ansi run python -- -V
USAGE
  poetry help [<command1>] ... [<commandN>]
...

This is really surprising and unexpected behavior. compare:

poetry run python abc
poetry run python --abc

in the former case, abc is passed to python, in the latter it is passed to poetry. It’s really weird that the discriminant is whether is an option or a vararg. afaict no state of the art cli behaves this way. if you really wanted to discriminate where an argument is passed, the docker behavior is more suitable

docker run --foo image bash # foo passed to docker
docker run image bash --foo # foo passed to subcommand

I’m experiencing this on Ubuntu 18 with 1.0.0b3 as well. An example when trying to invoke pre-commit:

15:15 $ poetry run pre-commit run --all-files

[NoSuchOptionException]
The "--all-files" option does not exist.

I can confirm that poetry run pre-commit -- run --all-files works. It seems like it doesn’t particularly matter where the -- gets put in the command as poetry run -- pre-commit run --all-files and poetry run pre-commit run -- --all-files seem to have the same effect.

I could show python --help with poetry run by following:

poetry run python -- --help

In Poetry version 1.0.0b3

I’m experiencing this on Ubuntu 18 with 1.0.0b3 as well. An example when trying to invoke pre-commit:

15:15 $ poetry run pre-commit run --all-files

[NoSuchOptionException]
The "--all-files" option does not exist.

For Pip:

pip3 install --user poetry==1.0.0b2 clikit==0.3.2

For those running into issues installing poetry==1.0.0.b1 with pipx, this is the workaround I did:

pipx install poetry==1.0.0.b1
pipx runpip poetry==1.0.0b1 install cleo==0.7.5 clikit==0.3.2