From Newsgroup: comp.lang.python

On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:

I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise
it's back to writing Yet Another C Program.

C would only be better if you could somehow get by with fewer
dependencies than with the Python equivalent. I’m not sure how you
would manage that -- reinvent more of your own wheels, perhaps?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/8/26 23:55, Lawrence D’Oliveiro wrote:

On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:

I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise
it's back to writing Yet Another C Program.

C would only be better if you could somehow get by with fewer
dependencies than with the Python equivalent. I’m not sure how you
would manage that -- reinvent more of your own wheels, perhaps?

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-03-09, c186282 <[email protected]> wrote:

On 3/8/26 23:55, Lawrence D’Oliveiro wrote:

On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:

I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise
it's back to writing Yet Another C Program.

C would only be better if you could somehow get by with fewer
dependencies than with the Python equivalent. I’m not sure how you
would manage that -- reinvent more of your own wheels, perhaps?

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

Python virtual environments do nothing whatsoever to stop you calling
whatever you like with "os.system()". A Python "virtual environment"
is simply a separate set of installed third-party library packages,
to avoid conflicts between the packages used by your program and
those used by other programs. You seem to be under the false impression
that it's some sort of chroot/jail/sandbox, and it simply isn't.
Python has no sandbox feature.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

If you actually want someone to help solve your problem then you’ll have
to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/9/26 09:59, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

COULD be ...

But I still note that things that worked clean
and easy pre-VENV now DON'T.

Who/what should I blame ?

There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.

If you actually want someone to help solve your problem then you’ll have
to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

I want the VENV *dead* ... CAN that be done ???

Or do I have to go back to 2020 versions of Linux ?

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

c186282 <[email protected]> writes:

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

You’ve not reported anything actionable. Some stuff doesn’t work from
your script, well so what? Without seeing concrete details, nobody can
tell whether there’s a real behavior change there or just a bug in your script. Since it all works fine for everyone else, the working
assumption is the latter.

I want the VENV *dead* ... CAN that be done ???

The answer to that has already been posted: if you are in a venv and
don’t want to be, just type ‘deactivate’.

Or do I have to go back to 2020 versions of Linux ?

venvs have been around for something like 15 years, so if the problem
was really venvs then dialing back to 2020 is unlikely to make a
difference.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/10/26 04:47, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

You’ve not reported anything actionable.

Then don't waste your time.

A report is a report.

If others experience the same issues maybe
they will go deeper into it, or not.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

In comp.os.linux.misc c186282 <[email protected]> wrote:

On 3/9/26 09:59, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

COULD be ...

But I still note that things that worked clean
and easy pre-VENV now DON'T.

Who/what should I blame ?

There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.

If you actually want someone to help solve your problem then you’ll have >> to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

I want the VENV *dead* ... CAN that be done ???

And, again, much as Jon said, you are blaming "venv's" but given us no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/10/26 10:55, Rich wrote:

In comp.os.linux.misc c186282 <[email protected]> wrote:

On 3/9/26 09:59, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

COULD be ...

But I still note that things that worked clean
and easy pre-VENV now DON'T.

Who/what should I blame ?

There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.

If you actually want someone to help solve your problem then you’ll have >>> to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

I want the VENV *dead* ... CAN that be done ???

And, again, much as Jon said, you are blaming "venv's" but given us no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.

Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)

Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-03-10, c186282 <[email protected]> wrote:

On 3/10/26 10:55, Rich wrote:

In comp.os.linux.misc c186282 <[email protected]> wrote:

On 3/9/26 09:59, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

COULD be ...

But I still note that things that worked clean
and easy pre-VENV now DON'T.

Who/what should I blame ?

There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.

If you actually want someone to help solve your problem then you’ll have >>>> to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

I want the VENV *dead* ... CAN that be done ???

And, again, much as Jon said, you are blaming "venv's" but given us no
examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.

Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)

Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.

This not only isn't true, it cannot be true, because *by definition*
if the environment you're seeing is the same one Python always sees
then it isn't a "virtual" environment, it's the system environment.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

c186282 <[email protected]> writes:

On 3/10/26 10:55, Rich wrote:

And, again, much as Jon said, you are blaming "venv's" but given us
no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python
than you do, something to analyze and maybe show you where the
problem really exists.

To do that they would have to want their problem to be solved, rather
than to have something external to blame for it.

Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)

You’ve already been told how to exit a venv twice.

Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.

It is not.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

In comp.os.linux.misc c186282 <[email protected]> wrote:

On 3/10/26 10:55, Rich wrote:

In comp.os.linux.misc c186282 <[email protected]> wrote:

On 3/9/26 09:59, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

COULD be ...

But I still note that things that worked clean and easy pre-VENV
now DON'T.

Who/what should I blame ?

There's no POINT in a 'virtual environment/machine' unless you
PLAN to isolate the base machine from the application to various
degrees.

If you actually want someone to help solve your problem then
you’ll have to accurately describe what you are trying and what is
happening. In practice this means posting the exact code you are
using and exactly what happens when you run it.

Too fuckin' old now, not gonna get into a million details and
sub-sub-sub-config-files. I just report that some lower-level
OS commands no longer work as expected, or at all, using the
usual Python utilities for doing so.

I want the VENV *dead* ... CAN that be done ???

And, again, much as Jon said, you are blaming "venv's" but given us
no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python
than you do, something to analyze and maybe show you where the
problem really exists.

Can't figure out how to zap the VENV in order to provide the
examples you'd like :-)

In that case, how about a very simple example that fails, for you, so
the others here (Jon, etc.) can show you what you screwed up?

I predict no such example will be posted, since you seem to want to
bitch and complain about things you don't want to understand more than
you want to know why your system call isn't working.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 10/03/2026 18.03, c186282 wrote:
[...]

  Can't figure out how to zap the VENV in order
  to provide the examples you'd like  :-)

There are the following possibilities here:
1) You didn't properly get what a venv is in Python
2) You're trolling.

Assuming 1), the venv is nothing more that a
search path change, for Python programs and
modules. Where, instead of looking first into
the system folders, first is searched in the
venv "repository" area.
Nothing more, nothing less.

So, what do you want to "zap"?
There is nothing to "zap"...
Unless for "zapping" you meaning something
different. In case, please specify.

  Seems like, of late, it's entirely baked-in -
  Python is the VENV and the VENV is Python.

Non clear what this means, but maybe is the
same written above.

bye,
--

piergiorgio
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Tue, 10 Mar 2026 02:49:19 -0400, c186282 wrote:

Or do I have to go back to 2020 versions of Linux ?

You can, but you will have to learn how to use uv and you'll bitch about
that too.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Tue, 10 Mar 2026 13:03:49 -0400, c186282 wrote:

Can't figure out how to zap the VENV in order to provide the examples
you'd like

Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.

Unless you've specifically created a venv, you're not in one. I have a
script that scrapes the current conditions and forecasts from the NOAA
site. It uses two imports.

import json
import requests

json is built in, requests is in the dist-packages.

$ python3 -m site
sys.path = [
'/',
'/usr/lib/python313.zip',
'/usr/lib/python3.13',
'/usr/lib/python3.13/lib-dynload',
'/usr/local/lib/python3.13/dist-packages',
'/usr/local/lib/python3.13/dist-packages/opensky_api-1.3.0-
py3.13.egg',
'/usr/lib/python3/dist-packages',
]

in this case 'ls /usr/lib/python3/dist-packages' will show you what is available. Distros install many as a default. Others can be added like

'sudo apt install python3-numpy'

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Tue, 10 Mar 2026 18:13:38 -0000 (UTC), Rich wrote:

I predict no such example will be posted, since you seem to want to
bitch and complain about things you don't want to understand more than
you want to know why your system call isn't working.

FFmpeg is all screwed up in Debian Trixie
I can't install VirtualBox in Fedora.
Adding kvm to the kernel by default screwed everything up.
Linux Mint is hosed, too.
Got a VM up but ffmpeg still doesn't work.
Trying something with Python but that doesn't work.
The venv I'm probably not in screwed everything up.
Nah, I don't want to do that; it might work.

I think I'm seeing a pattern here. I'll ask Claude.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/10/26 13:09, Jon Ribbens wrote:

On 2026-03-10, c186282 <[email protected]> wrote:

On 3/10/26 10:55, Rich wrote:

In comp.os.linux.misc c186282 <[email protected]> wrote:

On 3/9/26 09:59, Richard Kettlewell wrote:

c186282 <[email protected]> writes:

The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.

Well, sometimes, I *want* to crash the box.

As Jon says, you’ve misdiagnosed your problem.

COULD be ...

But I still note that things that worked clean
and easy pre-VENV now DON'T.

Who/what should I blame ?

There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.

If you actually want someone to help solve your problem then you’ll have
to accurately describe what you are trying and what is happening. In >>>>> practice this means posting the exact code you are using and exactly >>>>> what happens when you run it.

Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.

I want the VENV *dead* ... CAN that be done ???

And, again, much as Jon said, you are blaming "venv's" but given us no
examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.

Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)

Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.

This not only isn't true, it cannot be true, because *by definition*
if the environment you're seeing is the same one Python always sees
then it isn't a "virtual" environment, it's the system environment.

OK, tomorrow, HOW do I start a Py3 that's NOT in
the VENV ???

Go ahead, search - I have. All the 'fixes' don't
work anymore.

Many say "no problem" - yet NO current workarounds.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Wed, 11 Mar 2026 02:48:33 -0400, c186282 wrote:

OK, tomorrow, HOW do I start a Py3 that's NOT in the VENV ???

Go ahead, search - I have. All the 'fixes' don't work anymore.

Many say "no problem" - yet NO current workarounds.

What the fuck are you trying to do?

$ python3
Python 3.13.7 (main, Jan 22 2026, 20:15:57) [GCC 15.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

At the command prompt you can do interactive.

python3 foo,py

runs foo.py.

I finally found a use for the caps lock.

YOU'RE NOT IN A FUCKING VENV UNLESS YOU CREATE IT, GO INTO THE DIRECTORY
AND RUN '. bin/activate

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

c186282 <[email protected]> writes:

On 3/10/26 13:09, Jon Ribbens wrote:

On 2026-03-10, c186282 <[email protected]> wrote:

Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)

Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.

This not only isn't true, it cannot be true, because *by definition*
if the environment you're seeing is the same one Python always sees
then it isn't a "virtual" environment, it's the system environment.

OK, tomorrow, HOW do I start a Py3 that's NOT in
the VENV ???

You’ve been told how to exit venvs more than once. If you can’t follow simple instructions, that’s a problem with you, not Python.

Go ahead, search - I have. All the 'fixes' don't
work anymore.

Many say "no problem" - yet NO current workarounds.

Multiple people are trying to help you, for increasingly opaque
reasons. You’ll get nowhere until you actually start following their
advice.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-03-11, c186282 <[email protected]> wrote:

On 3/10/26 13:09, Jon Ribbens wrote:

This not only isn't true, it cannot be true, because *by definition*
if the environment you're seeing is the same one Python always sees
then it isn't a "virtual" environment, it's the system environment.

OK, tomorrow, HOW do I start a Py3 that's NOT in
the VENV ???

On any normal system, you type "python3".

Go ahead, search - I have. All the 'fixes' don't
work anymore.

Many say "no problem" - yet NO current workarounds.

The problem is you've consistently refused to explain why you think
it is in a "VENV", and what you actually mean by that.

Here's a guess: did you install python using dnf, snap or flatpak,
or something else? If you type "which python3", what does it say?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 10/03/2026 18:14, Piergiorgio Sartor wrote:

2) You're trolling.

My money is on this option.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 3/10/26 18:14, Piergiorgio Sartor wrote:

On 10/03/2026 18.03, c186282 wrote:
[...]

   Can't figure out how to zap the VENV in order
   to provide the examples you'd like  :-)

There are the following possibilities here:
1) You didn't properly get what a venv is in Python
2) You're trolling.

Assuming 1), the venv is nothing more that a
search path change, for Python programs and
modules. Where, instead of looking first into
the system folders, first is searched in the
venv "repository" area.
Nothing more, nothing less.

My understanding is different. My understanding is that a venv only uses packages installed locally in the venv. It shouldn't default to a
global package if it is not found in the venv.

(caveat: it may use default site installed packages if told to do so).

This is very much what I would want. I would want my python app to work independently of some eccentricity of the machine I develop on. I
suspect if I were still a developer I would go further and use
snaps,flatpak, or docker containers.



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 11/03/2026 21.19, Pancho wrote:
[...]

My understanding is different. My understanding is that a venv only uses packages installed locally in the venv.  It shouldn't default to a
global package if it is not found in the venv.

This happened to me, so I removed almost
all (non critical) system packages.

(caveat: it may use default site installed packages if told to do so).

Maybe it was my initial setup like this.

In any case, what I wanted to say is that
the venv is not like a virtual machine,
but just a different module search order.

bye,
--

piergiorgio
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Wed, 11 Mar 2026 20:19:35 +0000, Pancho wrote:

I would want my python app to work independently of some
eccentricity of the machine I develop on.

Better still, document your dependencies, and include a list of them
in the installation procedure for your app.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Wed, 11 Mar 2026 21:35:04 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Wed, 11 Mar 2026 20:19:35 +0000, Pancho wrote:

I would want my python app to work independently of some eccentricity
of the machine I develop on.

Better still, document your dependencies, and include a list of them in
the installation procedure for your app.

That's where 'pip freeze > requirements.txt' comes in. Use the -l argument
if the venv referenced the system site-packages or it will be a huge list.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-03-11, Pancho wrote:

On 3/10/26 18:14, Piergiorgio Sartor wrote:

On 10/03/2026 18.03, c186282 wrote:
[...]

   Can't figure out how to zap the VENV in order
   to provide the examples you'd like  :-)

There are the following possibilities here:
1) You didn't properly get what a venv is in Python
2) You're trolling.

Assuming 1), the venv is nothing more that a
search path change, for Python programs and
modules. Where, instead of looking first into
the system folders, first is searched in the
venv "repository" area.
Nothing more, nothing less.

My understanding is different. My understanding is that a venv only
uses packages installed locally in the venv. It shouldn't default to
a global package if it is not found in the venv.

I guess the other view is to allow package management to exist and work,
and using venvs only for what can't be managed by the package manager...

(caveat: it may use default site installed packages if told to do so).

... but then I guess that's what stuff managed by the package manager
ends up as?

This is very much what I would want. I would want my python app to
work independently of some eccentricity of the machine I develop on. I suspect if I were still a developer I would go further and use
snaps,flatpak, or docker containers.

At this point, why not also use static linking?
--
Nuno Silva
(not reading comp.lang.python)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Thu, 12 Mar 2026 10:39:42 +0000, Nuno Silva wrote:

I guess the other view is to allow package management to exist and work,
and using venvs only for what can't be managed by the package manager...

The packages available from a distro's repository may not be current. Stay within the limits of what you can do with the system packages, and you're fine.

However if you're in the habit of using venvs it's no big deal and you are consistent, not wondering if you'll need one or not as the project
progresses.

fwiw, this whole thread started from an simple minded attempt to invoke
sudo from a Python script. I doubt that ever worked in any version of
Python and would be an obvious security problem.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Wed, 11 Mar 2026 08:40:36 +0000, Richard Kettlewell wrote:

that’s a problem with you

That moron you are replying to is a windrone. It can't learn, it needs its clickety-click-click-click GUI to make sense of the simplest of tasks.

See also:
THBNATCCH (Thick Headed Baboon No Amount of Typewriters Can Cure Him)

Don't engage, KF and desist, it'll eventually go away.

Follow-up set to:
alt.extreme-one.lameass.troll (that's probably his birthplace)
--
Gilmeh

Gee, I feel kind of LIGHT in the head now, knowing I can't make my
satellite dish PAYMENTS!
--- Synchronet 3.21d-Linux NewsLink 1.2