Funny error message

[DL Neil]

On 1/2/21 9:39 AM, Bob van der Poel wrote:
> 
> 
> On Fri, Jan 1, 2021 at 12:17 PM DL Neil via Python-list
> <python-list at python.org <mailto:python-list at python.org>> wrote:
> 
>     On 1/2/21 6:35 AM, Bob van der Poel wrote:
>     > Found it!
> 
>     Well done!
> 
> 
>     >>     I had the proper urllib3 installed. But, in my .local/lib/ a
>     previous
>     >>     version was installed. Removing .local/lib/python3.8 has
>     resolved the
>     >>     problem.
>     >>
>     >>     Anyone hazard a guess as to why I had a .local tree (nope, I did
>     >>     not create
>     >>     it ... I don't think!).
>     >>
>     >
>     >     That is where "python3.8 -m pip install --user" puts the packages
>     >     you install.
>     >
>     >     Barry
>     >
>     >
>     >
>     > Okay ... I'll take your word for it. But, I really don't think I've
>     > every run that command :)
> 
>     Assuming Python is maintained only at the system-level (cf --user or
>     venv) then it may be possible that installing some application that runs
>     'on' Python added the local-library (as a "dependency"). Alternately,
>     many beginners following installation instructions on a paint-by-numbers
>     basis, may type/copy-paste commands without retaining any memory of
>     same.
>     [observation, not personal criticism]
> 
>     Python has been designed to offer flexibility. One of which is the
>     ability to have multiple, co-resident, versions of Python and/or
>     libraries. Of course, this also produces exactly the type of 'gotcha'
>     illustrated (detected, and solved) here.
> 
>     Someone more familiar with Python-packaging may improve/correct...
> 
> 
>     On a thematically-related, but OT-note:
>     I decided to install a 'fresh' version of Fedora 33 on this machine,
>     rather than performing a version-update. (required one hour from
>     start-to-finish - try that MS-Win users!) The Python-relevance was to
>     ensure there was no legacy-Python2 left 'lying-around'. However, the
>     GIMP (popular graphics package) still uses (and has some sort of
>     'exemption' to use) Python2. Stymied! Not quite - there's a Flatpak
>     option - which will enable my Python3-only objective by ring-fencing the
>     GIMP and its dependencies. However... now I have a system package
>     manager (dnf (~apt)) installing most system-software and 'other stuff'
>     under a different method (I took the same approach with the Chromium
>     browser) - how long will it be before such 'cleverness' is
>     forgotten/trips me up?
> 
> 
> I have installed a few packages using pip. I "try" to do so as root
> (this is basically a one user machine) ... but I may have installed as
> user. Still, it should not have brought in a complete py set of
> libraries. I'm going with the idea that some other package, either via
> apt or flatpak (which I really don't trust) decided to be nice. But it
> was a mess to have python distros in /usr/lib, /usr/local/lib and
> ./local ... I am going to really try in the future to have everything in
> one spot!

I'm not sure if you mean that you intend moving files from the directory
where they were loaded to somewhere else - I would hesitate!


As before, there is a tradeoff between 'tidiness' and 'flexibility'.
Perhaps do some reading to ensure a grasp of Python's library/directory
structures and system/virtual environments, first?

Suggestions:
sys.path https://docs.python.org/3/using/cmdline.html
2.3. Python-related paths and files
https://docs.python.org/3/using/unix.html#python-related-paths-and-files
PEP 370 -- Per user site-packages directory
https://www.python.org/dev/peps/pep-0370/
and to really dive 'under the covers'
https://www.python.org/dev/peps/pep-0587/
- with plenty more, both on-site and externally.

It quickly becomes apparent that there are risks in assuming that what
'should be done' for one project/application will 'always' be OK. Sadly,
such may have an (undesirable) impact on another/others. Thus, the
virtue of project-dedicated venvs (alternately OpSys-level containers)!


> Speaking of "one spot" I also see that some functions do not create the
> .pyc versions. Running as a user, the compressed version can't be
> created in /usr/lib/. I assume the installer is supposed to do that, but
> it does appear that it's not 100%.

There are multiple reasons for this, but the first time that code is
run, a .pyc will (presumably) be created - and we're back to
considerations of Python environments, Python cf C, perhaps even
differences between OpSys - certainly and once-again, 'here be dragons'...
-- 
Regards =dn