On Sun, 8 Mar 2026 05:31:16 -0400, c186282 wrote:
Alas Python is no longer "real" ... lives in a horrible "virtual
environment" that seems to lock out a lot of useful stuff "for your
safety".
I started using venvs long ago but it is getting more painful. One thing I've started doing is
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
rbowman <bowman@montana.com> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ?duelling
packaging systems? mess, and looks like it?s straightforward to override
the restriction if appropriate.
On 2026-03-08, Richard Kettlewell <invalid@invalid.invalid> wrote:
rbowman <bowman@montana.com> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ?duelling
packaging systems? mess, and looks like it?s straightforward to override
the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
On Sun, 08 Mar 2026 22:05:37 +0000, Richard Kettlewell wrote:
rbowman <bowman@montana.com> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ?duelling
packaging systems? mess, and looks like it?s straightforward to override
the restriction if appropriate.
I've gotten used to it and don't find it cumbersome but I also use dotnet, express, arduino_cli that generate the skeleton of a project.
I've never tried a package that Fedora wants to install to the user's
space. Arch generates an error similar to the Ubuntu one. ruff isn't a
good test on either of those since both distros have a python-ruff package that can be installed with dnf or pacman. I don't know why Ubuntu doesn't since ruff is a general purpose tool like black. The PEP does say distros roll their own. As the distros use more Python behind the scenes they have
a real interest in people not randomly installing to the system packages.
I fired up the Leap 16 VM and it gives the same external message as
Fedora. 'sudo zypper install python3-ruff' works on that too.
There may still be more forgiving distros but with the Debian, Arch,
Fedora, and SUSE families working mostly the same I think C12345 better embrace venv.
On 3/8/26 20:27, Charlie Gibbs wrote:
On 2026-03-08, Richard Kettlewell <invalid@invalid.invalid> wrote:
rbowman <bowman@montana.com> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ?duelling
packaging systems? mess, and looks like it?s straightforward to override >>> the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
At some point the 'idealists' can degrade and ruin
a perfectly good thing. The idea of a Python VE is
a stone on this road to ruin.
Oh well, I've done a lot of Pascal and 'C' ... so
as needed I can go there. Python IS super handy
however and has a a lib for everything.
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.
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 2026-03-09, c186282 <c186282@nnada.net> wrote:
On 3/8/26 20:27, Charlie Gibbs wrote:
On 2026-03-08, Richard Kettlewell <invalid@invalid.invalid> wrote:
rbowman <bowman@montana.com> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt >>>>> to herd you into a venv.
The design seems better than defaulting to getting into a ?duelling
packaging systems? mess, and looks like it?s straightforward to override >>>> the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
At some point the 'idealists' can degrade and ruin
a perfectly good thing. The idea of a Python VE is
a stone on this road to ruin.
Oh well, I've done a lot of Pascal and 'C' ... so
as needed I can go there. Python IS super handy
however and has a a lib for everything.
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.
Charlie Gibbs <cgibbs@kltpzyxm.invalid> 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.
Not necessarially. If the "GUI gadgets" were from the Tkinter package,
then the GUI gadgets were actually Tk widgets from the TCL world. So
you could also sidestep all the python venv silliness by writing that
GUI in TCL instead (and if it's just calling out to other programs to
do the real work, the amount of TCL necessary to glue a GUI to another program is small).
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.
On Sun, 8 Mar 2026 21:14:00 -0400, c186282 wrote:
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I disagree. VEs save you from the equivalent of dll hell someplace down
the road. Dotnet, Angular, Node, and others are similar now. Your project encapsulates the dependencies it needs. Another project may require different versions. For example with node anything you install for the project goes into node_modules and package.json has the dependencies for that project:
"dependencies": {
"cookie-parser": "~1.4.4",
"debug": "~2.6.9",
"express": "^4.21.2",
"fs": "^0.0.1-security",
"leaflet": "^1.9.4",
"leaflet-gpx": "^2.2.0",
"morgan": "~1.9.1"
}
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.
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.
Stick to tkinter and you *should* be good. I say should because 'import tkinter' works on Mint, Ubuntu, and Fedora. On Leap you'd have to do
'zypper install python-tk' but it would then be global. Arch says it's python isn't configured for Tk.
On 2026-03-09, rbowman <bowman@montana.com> 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.
Stick to tkinter and you *should* be good. I say should because 'import
tkinter' works on Mint, Ubuntu, and Fedora. On Leap you'd have to do
'zypper install python-tk' but it would then be global. Arch says it's
python isn't configured for Tk.
My little test program uses tkinter, and runs fine on Debian Bookworm.
Looks like a good start...
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 Sun, 8 Mar 2026 21:14:00 -0400, c186282 wrote:
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I disagree. VEs save you from the equivalent of dll hell someplace down
the road. Dotnet, Angular, Node, and others are similar now. Your project encapsulates the dependencies it needs. Another project may require
different versions. For example with node anything you install for the project goes into node_modules and package.json has the dependencies for
that project:
"dependencies": {
"cookie-parser": "~1.4.4",
"debug": "~2.6.9",
"express": "^4.21.2",
"fs": "^0.0.1-security",
"leaflet": "^1.9.4",
"leaflet-gpx": "^2.2.0",
"morgan": "~1.9.1"
}
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 ???
On Sun, 8 Mar 2026 21:14:00 -0400, c186282 wrote:+1.
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I disagree. VEs save you from the equivalent of dll hell someplace down
the road.
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 Tue, 10 Mar 2026 06:21:17 -0400, c186282 wrote:
Hmmm ... Python worked GREAT *before* the VENV ...
no 'hell'.
Until it didn't. The install of the Esri desktop included a Python2.7 directory that had Python with their secret sauce added. It did not play
well if you had Python from python.org installed. When they finally
migrated to Python 3 they used conda for the installation. That REALLY
didn't play well.
Then there was ActiveState Python, originally designed for Windows with packages to leverage the Windows API. They also had a Perl installation.
Sure, you could use Python casually and not run into any problems. You
still can if you don't want packages that aren't included in the distro's site-packages.
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.
Attempting 'os.exec("sudo killall -9 ffmpeg")'
after each cycle, but that seems to be one of
the system things the VENV won't pass properly.
Works perfectly from a real CL, but not from
within the Py app.
c186282 <c186282@nnada.net> wrote:
Attempting 'os.exec("sudo killall -9 ffmpeg")'
after each cycle, but that seems to be one of
the system things the VENV won't pass properly.
Works perfectly from a real CL, but not from
within the Py app.
When you invoke from a "real CL" does sudo request your password?
If yes, then how the fuck do you think doing os.exec from within a
Python script is going to prompt you for your password? Esp. if it
(Python) is doing so after hours of ffmpeg time and you are not around.
The sudo is most likely why your os.exec() is failing.
Rich <rich@example.invalid> writes:
c186282 <c186282@nnada.net> wrote:
Attempting 'os.exec("sudo killall -9 ffmpeg")'
after each cycle, but that seems to be one of
the system things the VENV won't pass properly.
Works perfectly from a real CL, but not from
within the Py app.
When you invoke from a "real CL" does sudo request your password?
If yes, then how the fuck do you think doing os.exec from within a
Python script is going to prompt you for your password? Esp. if it
(Python) is doing so after hours of ffmpeg time and you are not around.
The sudo is most likely why your os.exec() is failing.
First, being run from a Python script does not prevent sudo from
prompting for a password. I?ve no idea why you?d think it would.
Second, there is no such thing as os.exec.
>>> import os
>>> help(os.exec)
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
help(os.exec)
^^^^^^^
AttributeError: module 'os' has no attribute 'exec'. Did you mean: 'execl'?
If c186282 is actually using os.exec, then that?s their surface-level problem.
Alternatively they may be referring to os.execl, etc. Those are still
the wrong APIs for most use cases, since they replace the running
process. You have to read the first line of the documentation to
discover this point, so perhaps it?s understandable why someone might
have missed it.
If you actually want to run subprocesses from Python scripts then
os.system is the best option for simple use cases, and the subprocess
module for anything more complex.
>>> import os
>>> os.system("sudo id")
[sudo] password for richard:
uid=0(root) gid=0(root) groups=0(root)
0
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.
c186282 seems to be trying to create a background deamon to monitor for
his /supposed/ stuck ffmpeg and kill ffmpeg when a stuck condition is
found. In which case, there's likely no user watching the terminal (or
no actual terminal in any case) to which to prompt, so even if c186282
used os.system, the result would still not reset the stuck ffmpegs
since either there's no one around to type in the password, or there's
no controlling terminal to which to prompt.
And, as I did say in my post, if both the monitor and ffmpeg are the
same user, there's zero need for 'sudo' to kill (or killall) the ffmpeg process. And given that is is very likely this monitor and the ffmpeg process are both running as the same user, prefixing 'sudo' there
simply shows a fundamental lack of understanding on c186282's part for
what sudo is for and why it is used.
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 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.
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: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 121:23:58 |
| Calls: | 125 |
| Calls today: | 125 |
| Files: | 489 |
| D/L today: |
859 files (365M bytes) |
| Messages: | 76,611 |
| Posted today: | 26 |