venv and executing other python programs

[Roel Schroeven]

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.

-- 
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools."
         -- Douglas Adams