venv and executing other python programs

[Chris Angelico]

On Tue, 15 Feb 2022 at 21:19, Roel Schroeven <roel at roelschroeven.net> wrote:
>
> Op 15/02/2022 om 8:21 schreef Reto:
> > On Tue, Feb 15, 2022 at 06:35:18AM +0100, Mirko via Python-list wrote:
> > > How to people here deal with that?
> >
> > Don't activate the venv for those programs then?
> > The point of a venv is that you only enter it when you actually want
> > that specific python stack.
> >
> > Get yourself a terminal that can either multiplex, or add something like
> > tmux or screen to the mix if you frequently need other python tools
> > during development.
> > Or just install those in you venv, after all if you
> > do use them for dev they are part of your dependencies, so declare them
> > as such.
> Still feels like a problem to me though.
>
> Suppose you're working on a program which, for example, prints json to
> stdout. And suppose you want to use a tool like jq (let's call it pjq as
> an example) to process that output, by piping the output of your program
> to it:
>
>      python your-program.py | pjq
>
> That seems to me a very sensible thing to do. If pjq is written in C,
> C++, Rust, Ruby, PHP, Go, or whatever, itis not a problem at all. To the
> user of pjq, it shouldn't matter at all in what language it's written,
> and mostly it doesn't matter at all indeed.
>
> But if pjq happens to be written in Python, it suddenly matters very
> much: it won't work in your venv (unless your venv happens to have the
> right modules).
>
> There are ways around it of course:
> - install the tool in your venv, like you say
> - from outside the venv: venv/bin/python your_program.py | pjq
> - from inside the venv: python your_program.py | <global python
> interpreter> <path-to-pjq>
> Or something like that. At least I think those should work, I haven't
> tested it.
>
> But it feels to wrong to have to use such workarounds simply because pjq
> happens to be written in the same language as you're writing your
> program in.
>

The pjq shebang shouldn't specify /usr/bin/env unless you want it to
run in whatever Python is the current default. In other words, if it
matters, be more specific. That usually means either using
/usr/bin/python3 for your system Python, or the interpreter out of the
venv itself - /path/to/venv/bin/python3 - to specify that.

You're absolutely right, workarounds like that are wrong. But the
wrongness comes from using env when you don't want env :)

ChrisA