Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #197053 > unrolled thread

it's a shame... python error over error

Back to article view | Back to comp.lang.python

Contents

  it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 11:36 +0100
    Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 11:44 +0100
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 11:49 +0100
    Re: it's a shame... python error over error Barry <barry@barrys-emacs.org> - 2024-12-13 18:24 +0000
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-13 21:56 +0100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-14 08:27 -0700
    Re: it's a shame... python error over error "Peter J. Holzer" <hjp-python@hjp.at> - 2024-12-14 10:56 +0100
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-14 18:31 +0100
        Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-15 06:12 +1100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-14 22:21 -0700
    Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-14 08:30 -0700
    Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-16 08:08 +0100
      Re: it's a shame... python error over error "Peter J. Holzer" <hjp-python@hjp.at> - 2024-12-16 16:30 +0100
      Re: it's a shame... python error over error Grant Edwards <grant.b.edwards@gmail.com> - 2024-12-16 14:06 -0500
      Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-17 21:30 -0700
    Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-25 12:05 +0100
      Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-25 12:20 +0100
        Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-26 09:55 +1100
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:34 +0100
            Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-30 17:10 +1100
            Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-30 10:29 -0700
              Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2025-01-03 23:16 +0100
                Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2025-01-04 09:25 +1100
                Re: it's a shame... python error over error (Posting On Python-List Prohibited) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-03 23:17 +0000
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-25 20:55 -0700
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:42 +0100
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:47 +0100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-25 20:57 -0700
        Re: it's a shame... python error over error Chris Angelico <rosuav@gmail.com> - 2024-12-26 16:46 +1100
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-26 08:35 +0100
        Re: it's a shame... python error over error Michael Torrie <torriem@gmail.com> - 2024-12-26 11:33 -0700
          Re: it's a shame... python error over error aotto1968 <aotto1968@t-online.de> - 2024-12-27 07:46 +0100

Page 2 of 2 — ← Prev page 1 [2]

#197123

On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
> sorry you don't understand the problem…
> 
>  > You managed to make a build of Python that attempts to link to a DLL
> 
> I never touch the OpenSUSE python. the OpenSUSE python try to use my
> sqalite3.

The *only* mechanism that would cause the system python binary to try to
load modules and libraries from your local install is your environment
(environment variables).

[toc] | [prev] | [next] | [standalone]

#197136

On 30.12.24 18:29, Michael Torrie wrote:
> On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
>> sorry you don't understand the problem…
>>
>>   > You managed to make a build of Python that attempts to link to a DLL
>>
>> I never touch the OpenSUSE python. the OpenSUSE python try to use my
>> sqalite3.
> 
> The *only* mechanism that would cause the system python binary to try to
> load modules and libraries from your local install is your environment
> (environment variables).
> 

that is right because MY environment variable point to MY local user stuff.

The CORE problem is that OpenSUSE (Linux) python use MY env.

If I call a OS feature like "cnf" this should NOT interact with my private user stuff.

the OpenSUSE do it right because OpenSUSE use /usr/bin/python in "cnf" BUT the
python think to interact with MY env.

To make it short: The OS python will NEVER proper work if LOCAL user stuff is used.

[toc] | [prev] | [next] | [standalone]

#197137

On Sat, 4 Jan 2025 at 09:22, aotto1968 via Python-list
<python-list@python.org> wrote:
>
> On 30.12.24 18:29, Michael Torrie wrote:
> > On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
> >> sorry you don't understand the problem…
> >>
> >>   > You managed to make a build of Python that attempts to link to a DLL
> >>
> >> I never touch the OpenSUSE python. the OpenSUSE python try to use my
> >> sqalite3.
> >
> > The *only* mechanism that would cause the system python binary to try to
> > load modules and libraries from your local install is your environment
> > (environment variables).
> >
>
> that is right because MY environment variable point to MY local user stuff.
>
> The CORE problem is that OpenSUSE (Linux) python use MY env.
>
> If I call a OS feature like "cnf" this should NOT interact with my private user stuff.
>
> the OpenSUSE do it right because OpenSUSE use /usr/bin/python in "cnf" BUT the
> python think to interact with MY env.
>
> To make it short: The OS python will NEVER proper work if LOCAL user stuff is used.

People have tried in vain to explain this to you. You refuse to
listen. Go and argue with your OS instead of us; we're not the ones in
charge of this. Maybe if you argue enough, you'll start to understand
what "make install" does.

ChrisA

[toc] | [prev] | [next] | [standalone]

#197139 — Re: it's a shame... python error over error (Posting On Python-List Prohibited)

On Fri, 3 Jan 2025 23:16:24 +0100, aotto1968 wrote:

> The CORE problem is that OpenSUSE (Linux) python use MY env.

It can only do what you tell it to do.

Don’t tell it to do that, then.

[toc] | [prev] | [next] | [standalone]

#197106

On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
> <python-list@python.org> wrote:
>> It is not only an *usage* error it is also an *security* error because:
>>
>> 1) "cnf" is using OS python
>> 2) os "root" python
>> 3) using **my** local non-root library

I think he means the cnf is using the "root" OS python in /usr/bin, but
/usr/bin/python3 is trying to import his local build of sqlite3, which
cause it to fail. I assume he would like cnf to not try to import his
local sqlite3, and instead use the normal system one. If this is the
case, then somehow his local, non-root sqlite3 library is being picked
up by the system version of python.

Aotto might want to run the "env" command and see if there are any
search paths that have to do with Python.  I can see how this could be a
security issue. If you can figure out what's happening you might want to
open a ticket with the OpenSUSE developers.  This is Python related, but
it's not necessarily python's fault per se.

[toc] | [prev] | [next] | [standalone]

#197111

On 26.12.24 04:55, Michael Torrie wrote:
> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
>> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
>> <python-list@python.org> wrote:
>>> It is not only an *usage* error it is also an *security* error because:
>>>
>>> 1) "cnf" is using OS python
>>> 2) os "root" python
>>> 3) using **my** local non-root library
> 
> I think he means the cnf is using the "root" OS python in /usr/bin, but
> /usr/bin/python3 is trying to import his local build of sqlite3, which
> cause it to fail. I assume he would like cnf to not try to import his
> local sqlite3, and instead use the normal system one. If this is the
> case, then somehow his local, non-root sqlite3 library is being picked
> up by the system version of python.
> 
> Aotto might want to run the "env" command and see if there are any
> search paths that have to do with Python.  I can see how this could be a
> security issue. If you can figure out what's happening you might want to
> open a ticket with the OpenSUSE developers.  This is Python related, but
> it's not necessarily python's fault per se.

Yes I using with *my* user *my* environment but never touch the *root*
environment at all.

the *root* python try to use *my* sqlite3 because *my* environment
fit to *my* needs.

/* just a reminder */

sqlite3 have a "special" (worse) setup that a change to the configuration
also change the "api" ( a sqlite_function disappear or arrive ).
If a tool like python using an extension that is linked to sqlite3 that extension
will likely FAIL is I get an OTHER sqlite3 which is NOT the one the extension
was build with.

[toc] | [prev] | [next] | [standalone]

#197112

On 26.12.24 04:55, Michael Torrie wrote:
> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
>> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
>> <python-list@python.org> wrote:
>>> It is not only an *usage* error it is also an *security* error because:
>>>
>>> 1) "cnf" is using OS python
>>> 2) os "root" python
>>> 3) using **my** local non-root library
> 
> I think he means the cnf is using the "root" OS python in /usr/bin, but
> /usr/bin/python3 is trying to import his local build of sqlite3, which
> cause it to fail. I assume he would like cnf to not try to import his
> local sqlite3, and instead use the normal system one. If this is the
> case, then somehow his local, non-root sqlite3 library is being picked
> up by the system version of python.
> 
> Aotto might want to run the "env" command and see if there are any
> search paths that have to do with Python.  I can see how this could be a
> security issue. If you can figure out what's happening you might want to
> open a ticket with the OpenSUSE developers.  This is Python related, but
> it's not necessarily python's fault per se.

You don't understand the problem if you think "/usr/bin/env"  will solve the
problem → this will make it more worse.

A "personal" python will use a "personal" configuration and probably is *not*
build with sqlite3 support at all.

a *root* tool should never ever use/call a non *root* (personal) setup.

[toc] | [prev] | [next] | [standalone]

#197107

On 12/25/24 8:55 PM, Michael Torrie wrote:
> This is Python related, but
> it's not necessarily python's fault per se.

It's also a good reminder to use venv.  Then there's no way of
activating your custom python with its custom sqlite3 library unless you
explicitly activate the venv.

[toc] | [prev] | [next] | [standalone]

#197108

On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list
<python-list@python.org> wrote:
>
> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
> > On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
> > <python-list@python.org> wrote:
> >> It is not only an *usage* error it is also an *security* error because:
> >>
> >> 1) "cnf" is using OS python
> >> 2) os "root" python
> >> 3) using **my** local non-root library
>
> I think he means the cnf is using the "root" OS python in /usr/bin, but
> /usr/bin/python3 is trying to import his local build of sqlite3, which
> cause it to fail. I assume he would like cnf to not try to import his
> local sqlite3, and instead use the normal system one. If this is the
> case, then somehow his local, non-root sqlite3 library is being picked
> up by the system version of python.

Right. That's exactly what would happen if he'd built Python using
absolute paths to libraries, which is the normal way to do it. And so
the solution is to rebuild Python using absolute paths to libraries.

ChrisA

[toc] | [prev] | [next] | [standalone]

#197110

On 26.12.24 06:46, Chris Angelico wrote:
> On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list
> <python-list@python.org> wrote:
>>
>> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
>>> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
>>> <python-list@python.org> wrote:
>>>> It is not only an *usage* error it is also an *security* error because:
>>>>
>>>> 1) "cnf" is using OS python
>>>> 2) os "root" python
>>>> 3) using **my** local non-root library
>>
>> I think he means the cnf is using the "root" OS python in /usr/bin, but
>> /usr/bin/python3 is trying to import his local build of sqlite3, which
>> cause it to fail. I assume he would like cnf to not try to import his
>> local sqlite3, and instead use the normal system one. If this is the
>> case, then somehow his local, non-root sqlite3 library is being picked
>> up by the system version of python.
> 
> Right. That's exactly what would happen if he'd built Python using
> absolute paths to libraries, which is the normal way to do it. And so
> the solution is to rebuild Python using absolute paths to libraries.
> 
> ChrisA

next I don't change the OpenSUSE python and the OpenSUSE python is using *my*
sqlite3.

[toc] | [prev] | [next] | [standalone]

#197114

On 12/25/24 10:46 PM, Chris Angelico wrote:
> Right. That's exactly what would happen if he'd built Python using
> absolute paths to libraries, which is the normal way to do it. And so
> the solution is to rebuild Python using absolute paths to libraries.

You're right. Definitely appears to be a pretty major mis-configuration
of his system. Not much we can do about that.

[toc] | [prev] | [next] | [standalone]

#197116

On 26.12.24 19:33, Michael Torrie wrote:
> On 12/25/24 10:46 PM, Chris Angelico wrote:
>> Right. That's exactly what would happen if he'd built Python using
>> absolute paths to libraries, which is the normal way to do it. And so
>> the solution is to rebuild Python using absolute paths to libraries.
> 
> You're right. Definitely appears to be a pretty major mis-configuration
> of his system. Not much we can do about that.
> 

no, your are wrong.

The problem is NOT that my user-account has a miss-configuration because my
user-account works pretty well…

The problem is that the *default* /usr/bin/python3 OpenSUSE installation using
parts of *my* local *user* setup.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web