Funny error message
DL Neil
PythonList at danceswithmice.info
Fri Jan 1 16:38:01 EST 2021
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
More information about the Python-list
mailing list