Add IPython inference support

[LaurenceWarne]

Hi! I was wondering if you'd be interested in adding something like an --ipython argument as a convenience argument to kick off an IPython interpreter rather than a standard python one.

General behaviour: Specifying pip-run --ipython is (mostly) equivalent to pip-run ipython -- -m IPython

pip-run --ipython foo  # starts an ipython interpreter with the dep 'foo'
pip-run --ipython foo -- -c "print('hi')"  # '--ipython' treated the same as 'ipython' (not particularly useful)

(for more info see the updated doc) And something like: alias pip-run="pip-run --ipython" works quite nicely. Its more of a... "bells and whistles" feature, so I'd understand 100% if you didn't want to include it. Let me know what you think anyway :slightly_smiling_face:

[jaraco]

This is an interesting idea.

If I were to accept it, I'd like to support more than just the bare interactive prompt, but instead allow any invocation of -m IPython ... (it accepts a lot of the same args as Python itself).

I'm a little uneasy about the --ipython argument, because it impedes the purity of the pip install args.

Based on this PR, I've started pondering some alternative convenience approaches.

explicit command implies dependency

In this approach, the ipython dependency would be implied by -m iPython. Then, instead of:

pip-run ipython <other deps...> -- -m iPython <args>

The ipython dependency would be implied:

pip-run <other deps...> -- -m iPython <args>

Of course, that's slightly less convenient than pip-run --ipython <other deps...> because it requires both the -- and -m IPython, which is slightly more verbose than --ipython.

This mode would be more useful if pip-run adopted another convenience feature to infer -m (anything) as indicating the start of Python args, so the -- would be optional (similar to how #59) infers Python args when it encounters a script file.

presence of IPython implies -m IPython

In this approach, if iPython is present in the environment, pip-run will automatically use IPython. Thus, one would invoke:

pip-run ipython <other deps...>

To get an interactive prompt, and pip-run ipython <other deps...> -- <other args...> to invoke -m IPython <other args...>.

This approach would also have the benefit of using IPython implicitly if one had previously installed IPython into the environment. e.g.

pip install IPython
pip-run <other deps...> -- <other args>

This option seems like the most convenient, but also is the most magical.

---

What do you think of these alternatives?

[LaurenceWarne]

Thanks for the in-depth rundown.

I'm a little uneasy about the --ipython argument, because it impedes the purity of the pip install args.

Yeah, that makes sense.

Personally, I think I'd prefer the latter idea. I think the main use case of anyone including ipython as a dep would be to run it as an interpreter, though on the flip side, as you say it's quite magical.

Another idea is the behaviour (of the latter approach) could be toggled on by some kind of user configuration option, AFAICS pip-run doesn't read any kind of persisted configuration, maybe pip config could be hijacked?

This approach would also have the benefit of using IPython implicitly if one had previously installed IPython into the environment. e.g.

Nice, I hadn't considered that!

[jaraco]

Another idea is the behaviour (of the latter approach) could be toggled on by some kind of user configuration option, AFAICS pip-run doesn't read any kind of persisted configuration, maybe pip config could be hijacked?

Since pip-run doesn't currently employ any file-based config options, I'd lean toward not changing that. I'd probably lean toward supporting an environment variable to customize the behavior.

How about let's make the behavior the default but honor a config option (env var) to opt-out?

[LaurenceWarne]

Since pip-run doesn't currently employ any file-based config options, I'd lean toward not changing that. I'd probably lean > toward supporting an environment variable to customize the behavior.

Understandable, in retrospect a whole new method for sourcing config options is probably not worth looking at for a somewhat niche feature like this.

How about let's make the behavior the default but honor a config option (env var) to opt-out?

:+1: Done in the latest commit! Seems tricky to unit test, but I've installed from source and it appears to work fine - ideas welcome.

[jaraco]

In the 11.0 release, I've renamed the variable to PIP_RUN_IPYTHON_MODE and expect the values infer (default) or ignore to bypass the behavior.