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.
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?
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.
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.
c186282 <c186282@nnada.net> 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.
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 ?
c186282 <c186282@nnada.net> writes:Then don't waste your time.
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.
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <c186282@nnada.net> 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 ???
In comp.os.linux.misc c186282 <c186282@nnada.net> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <c186282@nnada.net> 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.
On 3/10/26 10:55, Rich wrote:
In comp.os.linux.misc c186282 <c186282@nnada.net> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <c186282@nnada.net> 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.
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.
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.
On 3/10/26 10:55, Rich wrote:
In comp.os.linux.misc c186282 <c186282@nnada.net> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <c186282@nnada.net> 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 :-)
˙ 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.
On 2026-03-10, c186282 <c186282@nnada.net> wrote:
On 3/10/26 10:55, Rich wrote:
In comp.os.linux.misc c186282 <c186282@nnada.net> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <c186282@nnada.net> 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.
On 3/10/26 13:09, Jon Ribbens wrote:
On 2026-03-10, c186282 <c186282@nnada.net> wrote:
Can't figure out how to zap the VENV in orderThis not only isn't true, it cannot be true, because *by definition*
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.
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.
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 ???
Go ahead, search - I have. All the 'fixes' don't
work anymore.
Many say "no problem" - yet NO current workarounds.
2) You're trolling.
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).
I would want my python app to work independently of some
eccentricity of the machine I develop on.
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.
that?s a problem with you
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?
I just don't want applications built on quicksand libraries.
On Fri, 13 Mar 2026 09:34:06 +0000, Pancho wrote:
I just don't want applications built on quicksand libraries.
Depending on someone else?s library saves you effort. But then someone
else has to maintain the library.
Ever felt you could do with some help from those using a piece of
software you release? Those whose work you rely on feel the same way.
On 3/13/26 21:49, Lawrence D?Oliveiro wrote:
On Fri, 13 Mar 2026 09:34:06 +0000, Pancho wrote:
I just don't want applications built on quicksand libraries.
Depending on someone else?s library saves you effort. But then someone
else has to maintain the library.
Yeah, I don't know what point you are making?
On 3/13/26 21:49, Lawrence D?Oliveiro wrote:
On Fri, 13 Mar 2026 09:34:06 +0000, Pancho wrote:
I just don't want applications built on quicksand libraries.
Depending on someone else?s library saves you effort. But then someone
else has to maintain the library.
Yeah, I don't know what point you are making?
Ever felt you could do with some help from those using a piece of
software you release? Those whose work you rely on feel the same way.
Help from the people who used my software? Sometimes I used to do my
work amongst them, sit next to them, all day long, every day, just so I could spy on what they did. They wouldn't just tell me. If I was helpful they would ask me to do stuff, invest some time in explaining stuff to me.
On 3/13/26 19:28, Pancho wrote:
On 3/13/26 21:49, Lawrence D?Oliveiro wrote:
On Fri, 13 Mar 2026 09:34:06 +0000, Pancho wrote:
I just don't want applications built on quicksand libraries.
Depending on someone else?s library saves you effort. But then someone
else has to maintain the library.
Yeah, I don't know what point you are making?
˙ I sort of understand ... but, frankly, it is
˙ totally impractical to do ALL of your own
˙ code/libraries. 'C' came with a bunch, which
˙ rapidly became more numerous. Good Programmers
˙ wrote these and most serve VERY well for
˙ decades.
˙ Other langs follow this same pattern. Unless
˙ you're insane, and on huge doses of amphetamines,
˙ it is just not practical to do it ALL yourself.
˙ Hey, wanna write big apps in ASM ? Kinda DID that
˙ around the dawn of the PC era ... kinda fun then,
˙ but would NOT wanna try it now. Shouldn't HAVE to.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 195:47:49 |
| Calls: | 208 |
| Files: | 21,502 |
| Messages: | 84,363 |