Pipenv: `pipenv run` consumes flags anywhere in command line

[sersorrel]

0 $ pipenv run foo
The command (/home/josh/.local/share/virtualenvs/[redacted]/bin/foo) was not found within the virtualenv!
0 $ pipenv run foo --bar
The command (/home/josh/.local/share/virtualenvs/[redacted]/bin/foo) was not found within the virtualenv!
0 $ pipenv run foo --help
Usage: pipenv run [OPTIONS] COMMAND [ARGS]...

  Spawns a command installed into the virtualenv.

Options:
  --three / --two  Use Python 3/2 when creating virtualenv.
  --python TEXT    Specify which version of Python virtualenv should use.
  --help           Show this message and exit.

Instead, help text should only be printed if invoked with --help as first argument to run (i.e. pipenv run --help) -- even if a flag after the first argument to run is recognised as a pipenv flag, it should be passed to the program being run. IOW, pipenv run my_program --my-flag should always run my_program --my-flag, even if pipenv someday learns to recognise --my-flag.

Similarly with other options, not just --help:

$ pipenv run foo --python
Error: --python option requires an argument

(message is from pipenv, since foo binary doesn't exist)

Finally, pipenv run foo --three (or --two) removes the virtualenv automatically and creates a new one!

[nonylene]

You can use -- to signify the end of the options and pass arguments to the spawned command.

$ pipenv run -- foo --help
$ pipenv run -- foo --python
$ pipenv run -- my_program --my-flag

cf. http://click.pocoo.org/5/arguments/#option-like-arguments

[sersorrel]

Ah, thanks, that's a decent workaround.

[tammersaleh]

I was recently bit by this issue, and would like to ask that it be reconsidered. In particular, it'd be nice to be able to use a shebang line like #!/usr/bin/env pipenv run python at the top of a script. I don't think this is possible with the -- solution. This either forces developers to ship shim scripts to pass arguments along correctly, or users to understand the use of pipenv run with the --.

Would you consider simply passing through any arguments after the name of the script? ie:

• pipenv run --foo script.py would pass --foo to pipenv, but...
• pipenv run script.py --foo would pass --foo to the script

This is more intuitive and would solve the shebang issue.

[techalchemy]

@tsaleh this already addressed in #1047 and released in pipenv 9.0, if you upgrade (and then upgrade again to 9.0.1 for the bugfix release shortly) you shouldn't have this problem anymore

[tammersaleh]

@techalchemy oh, thanks! Sorry for the noise :)

[sersorrel]

@tsaleh btw, your idea of using a shebang like #!/usr/bin/env pipenv run python wouldn't work anyway, unfortunately – you'll get /usr/bin/env: ‘pipenv run python’: No such file or directory.

The format of a shebang is (from execve(2)):

#! interpreter [optional-arg]

so env would try to run a program called pipenv run python, instead of the intended behaviour of running pipenv with the arguments run and python.

[tammersaleh]

@anowlcalledjosh It's true that it's non-standard, and doesn't work on Linux, but it seems to work on MacOS. It's a good point that implementing this just for a non-standard implementation of execve is a poor idea. Still, I'm happy to see that this behavior was changed for consistency sake.

[tammersaleh]

Related, Bunder has an option for initializing the ruby environment _inside_ the ruby code (instead of prefixing the command line with bundle exec). Is this something Pipenv would consider? Is it even possible in Python? Is it being discussed anywhere?