On Tue, 15 Feb 2022 at 21:19, Roel Schroeven <r...@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 -- https://mail.python.org/mailman/listinfo/python-list