Mailing List Archive

On Sat, Mar 6, 2021 at 12:38 PM Steven Lembark <lembark@wrkhors.com> wrote:
<SNIP>
>
> $ which python3
> /usr/bin/python3
>
> $ ls -ld $(which python3)
> lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 ->
python-exec2c
>
> Thanks
>
What do you see just running python3 in a terminal?

- Mark

Hello,

On Sat, 06 Mar 2021, Steven Lembark wrote:
>Question then is why "python-exec2c" dispatched via a symlink from
>"python3" would fail to see the installed copy of pyyaml (or how
>should I check with modules are avalable via "python3")?
[..]
>I think that pyyaml is installed:
>
>* dev-python/pyyaml
> Latest version available: 5.4.1
> Latest version installed: 5.4.1
> Size of files: 170 KiB
> Homepage: https://pyyaml.org/wiki/PyYAML https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
> Description: YAML parser and emitter for Python
> License: MIT

Check with 'eix dev-python/pyyaml' or 'equery uses dev-python/pyyaml'
for what python versions that module is actually installed for and
compare that with the default python3 version (check 'python3 --version')

You probably need to re-emerge dev-python/pyyaml if PYTHON_TARGETS has
changed. You probably have it installed just for one target (which is
not your current default python3).

$ equery uses dev-python/pyyaml
[..]
+ + python_targets_python3_7 : Build with Python 3.7
+ + python_targets_python3_8 : Build with Python 3.8
- - python_targets_python3_9 : Build with Python 3.9
[..]

So I have it installed for python 3.7.x and 3.8.x ...

HTH,
-dnh

--
It's simply unbelievable how much energy and creativity people have
invested into creating contradictory, bogus and stupid licenses...
--- Sven Rudolph about licences in debian/non-free.

On Sun, 7 Mar 2021 00:09:47 +0100
David Haller <gentoo@dhaller.de> wrote:

> Hello,
>
> On Sat, 06 Mar 2021, Steven Lembark wrote:
> >Question then is why "python-exec2c" dispatched via a symlink from
> >"python3" would fail to see the installed copy of pyyaml (or how
> >should I check with modules are avalable via "python3")?
> [..]
> >I think that pyyaml is installed:
> >
> >* dev-python/pyyaml
> > Latest version available: 5.4.1
> > Latest version installed: 5.4.1
> > Size of files: 170 KiB
> > Homepage: https://pyyaml.org/wiki/PyYAML
> > https://pypi.org/project/PyYAML/ https://github.com/yaml/pyyaml
> > Description: YAML parser and emitter for Python License:
> > MIT
>
> Check with 'eix dev-python/pyyaml' or 'equery uses dev-python/pyyaml'
> for what python versions that module is actually installed for and
> compare that with the default python3 version (check 'python3
> --version')

I believe there isn't any PYTHON_TARGET-ish setting on the system:

$ grep PYTHON_TARGET /etc/portage/make.conf /etc/portage/package.use/*
/etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
/etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
/etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7

> You probably need to re-emerge dev-python/pyyaml if PYTHON_TARGETS has
> changed. You probably have it installed just for one target (which is
> not your current default python3).



> $ equery uses dev-python/pyyaml
> [..]
> + + python_targets_python3_7 : Build with Python 3.7
> + + python_targets_python3_8 : Build with Python 3.8
> - - python_targets_python3_9 : Build with Python 3.9
> [..]
>
> So I have it installed for python 3.7.x and 3.8.x ...
>
> HTH,
> -dnh
>

$ equery uses dev-python/pyyaml
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for dev-python/pyyaml-5.4.1:
U I
- - examples : Install examples, usually source code
+ + libyaml : enable support for C implementation using
libyaml
- - python_targets_python3_7 : Build with Python 3.7
+ + python_targets_python3_8 : Build with Python 3.8
- - python_targets_python3_9 : Build with Python 3.9
- - test : Enable dependencies and/or preparations
necessary to run tests (usually controlled by
FEATURES=test but can be toggled independently)
(ins)lembark@dizzy ~ $ eselect python list
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)

$ python3 --version;
Python 3.9.1


Q: If don't have PYTHON_TARGETS set

Given that I installed it yesterday when the makefile told me
about pyyaml not being installed, there aren't any TARGETS set
(both commented), python3 appears to be python-3.9...

Q: Why would emerge pyyaml install the pacakge for a non-target
python version that isn't the one linked via python3?

Q: Is this related to the fact that I'm not actually checking
python but a wrapper named "python-exec2c":

$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c


i.e., could the wrapper be mis-diagnosing the correct python
version at install time?

Q: Is there any reasonable way to have a single version of python
installed so that I get out of this maze? Previous python
target advice left me with one machine being re-installed and
I'd rather not have my server disabled at this point.

Thanks



--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Sun, 7 Mar 2021 at 17:00, Steven Lembark <lembark@wrkhors.com> wrote:
> I believe there isn't any PYTHON_TARGET-ish setting on the system:
>
> $ grep PYTHON_TARGET /etc/portage/make.conf /etc/portage/package.use/*
> /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
> /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7

What this is telling you is that you have no manual *override* of the
default python target setting. Check yours with something like:
$ emerge --info | grep PYTHON_TARGETS

The default at the moment is 3.8, and as eselect showed you, your
default python interpreter is 3.9. Did you set this explicitly? If you
have no particular need to move to 3.9 early, you could set 3.8 as the
default and probably be rid of your problems immediately.

> Q: Is this related to the fact that I'm not actually checking
> python but a wrapper named "python-exec2c":
>
> $ ls -l /usr/bin/python3
> lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 -> python-exec2c
>
>
> i.e., could the wrapper be mis-diagnosing the correct python
> version at install time?

It is finding python 3.9, which your system has set up to be the
wanted version. The link is the same on my system, but I have 3.8 as
my default interpreter, so I would not have these problems.

Regards,
Arve

On Sunday, 7 March 2021 17:03:22 GMT Arve Barsnes wrote:
> On Sun, 7 Mar 2021 at 17:00, Steven Lembark <lembark@wrkhors.com> wrote:
> > I believe there isn't any PYTHON_TARGET-ish setting on the system:
> > $ grep PYTHON_TARGET /etc/portage/make.conf
> > /etc/portage/package.use/*
> >
> > /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> > /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6
> > python3_7
> > /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6
> > python3_7
>
> What this is telling you is that you have no manual *override* of the
> default python target setting. Check yours with something like:
> $ emerge --info | grep PYTHON_TARGETS
>
> The default at the moment is 3.8, and as eselect showed you, your
> default python interpreter is 3.9. Did you set this explicitly? If you
> have no particular need to move to 3.9 early, you could set 3.8 as the
> default and probably be rid of your problems immediately.
>
> > Q: Is this related to the fact that I'm not actually checking
> >
> > python but a wrapper named "python-exec2c":
> > $ ls -l /usr/bin/python3
> > lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python3 ->
> > python-exec2c
> >
> > i.e., could the wrapper be mis-diagnosing the correct python
> > version at install time?
>
> It is finding python 3.9, which your system has set up to be the
> wanted version. The link is the same on my system, but I have 3.8 as
> my default interpreter, so I would not have these problems.
>
> Regards,
> Arve

While eselect python is still available the OP can run:

eselect python update
eselect python cleanup

> While eselect python is still available the OP can run:
>
> eselect python update
> eselect python cleanup

# eselect python update
Switching to python3.9
# eselect python cleanup
# eselect python list;
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)

Sanity check: Is this something I should be doing with
every python update (don't use python for anything myself
so if it works for system updates only I'm fine).


Thanks

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

Checking my environment, I'd expect that "python" is 3.9.1, I think?

# which python
/usr/bin/python

# ls -al /usr/bin/python
lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python -> python-exec2c

# /usr/bin/python --version;
Python 3.9.1

(ins)root@dizzy ~ # eselect python list;
Available Python interpreters, in order of preference:
[1] python3.9
[2] python3.6
[3] python3.8 (fallback)
[4] python3.7 (fallback)
[5] python2.7 (fallback)


Yet when I "emerge pyyaml" it seems to prefer 3.8 (see ? below):

(cmd)root@dizzy ~ # emerge pyyaml
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-python/pyyaml-5.4.1::gentoo
* pyyaml-5.4.1.gh.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking pyyaml-5.4.1.gh.tar.gz to /tmp/portage/dev-python/pyyaml-5.4.1/work
>>> Source unpacked in /tmp/portage/dev-python/pyyaml-5.4.1/work
>>> Preparing source in /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
* Applying pyyaml-5.1-cve-2017-18342.patch ... [ ok ]
>>> Source prepared.
>>> Configuring source in /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
? * Using python3.8 in global scope
? * python3_8: running distutils-r1_run_phase python_configure_all
>>> Source configured.
^C

Exiting on signal 2
>>> Compiling source in /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
^Csandbox:stop caught signal 2 in pid 8217
Sandboxed process killed by signal: Interrupt
* The ebuild phase 'die_hooks' has been killed by signal 2.

* Messages for package dev-python/pyyaml-5.4.1:
* Log file: /var/log/portage/dev-python:pyyaml-5.4.1:20210307-183833.log

Q: Is it reasonable to simply remove everything other than 3.9 and
some version of 2.7?

Trying to build 3.9 for one of my co-workers was hell, we ended up
using 3.8. Would it make more sense to remove 3.9?

Not entirely sure why I have so many versions of python left behind
by upgrades.

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Sunday, 7 March 2021 18:43:29 GMT Steven Lembark wrote:
> Checking my environment, I'd expect that "python" is 3.9.1, I think?
>
> # which python
> /usr/bin/python
>
> # ls -al /usr/bin/python
> lrwxrwxrwx 1 root root 13 Oct 20 10:46 /usr/bin/python -> python-exec2c
>
> # /usr/bin/python --version;
> Python 3.9.1
>
> (ins)root@dizzy ~ # eselect python list;
> Available Python interpreters, in order of preference:
> [1] python3.9
> [2] python3.6
> [3] python3.8 (fallback)
> [4] python3.7 (fallback)
> [5] python2.7 (fallback)
>
>
> Yet when I "emerge pyyaml" it seems to prefer 3.8 (see ? below):
>
> (cmd)root@dizzy ~ # emerge pyyaml
> Calculating dependencies... done!
>
> >>> Verifying ebuild manifests
> >>>
> >>> Emerging (1 of 1) dev-python/pyyaml-5.4.1::gentoo
>
> * pyyaml-5.4.1.gh.tar.gz BLAKE2B SHA512 size ;-) ...
> [ ok ]
> >>> Unpacking source...
> >>> Unpacking pyyaml-5.4.1.gh.tar.gz to
> >>> /tmp/portage/dev-python/pyyaml-5.4.1/work Source unpacked in
> >>> /tmp/portage/dev-python/pyyaml-5.4.1/work
> >>> Preparing source in
> >>> /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
> * Applying pyyaml-5.1-cve-2017-18342.patch ...
> [ ok ]
> >>> Source prepared.
> >>> Configuring source in
> >>> /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
> ? * Using python3.8 in global scope
> ? * python3_8: running distutils-r1_run_phase python_configure_all
>
> >>> Source configured.
>
> ^C
>
> Exiting on signal 2
>
> >>> Compiling source in
> >>> /tmp/portage/dev-python/pyyaml-5.4.1/work/pyyaml-5.4.1 ...
> ^Csandbox:stop caught signal 2 in pid 8217
> Sandboxed process killed by signal: Interrupt
> * The ebuild phase 'die_hooks' has been killed by signal 2.
>
> * Messages for package dev-python/pyyaml-5.4.1:
> * Log file:
> /var/log/portage/dev-python:pyyaml-5.4.1:20210307-183833.log
>
> Q: Is it reasonable to simply remove everything other than 3.9 and
> some version of 2.7?
>
> Trying to build 3.9 for one of my co-workers was hell, we ended up
> using 3.8. Would it make more sense to remove 3.9?
>
> Not entirely sure why I have so many versions of python left behind
> by upgrades.

Have you tried:

eselect python cleanup
emerge --depclean -v -p
emerge @preserved-rebuild -v -a

I don't have any python targets specified and on a (mostly) stable system I
get:

$ /usr/bin/python --version
Python 3.8.7

$ eselect python list
Available Python interpreters, in order of preference:
[1] python3.8
[2] python3.9 (fallback)

$ ls -al /usr/bin/python
lrwxrwxrwx 1 root root 13 Feb 13 09:04 /usr/bin/python -> python-exec2c

$ emerge -1Dvp pyyaml

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] dev-python/pyyaml-5.4.1::gentoo USE="libyaml -examples -
test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9" 170 KiB

Total: 1 package (1 new), Size of downloads: 170 KiB

It would use PYTHON_TARGETS="python3_8" which is the default on this system,
since I have not modified my python settings.

On Sun, 7 Mar 2021 11:00:16 -0500, Steven Lembark wrote:

> I believe there isn't any PYTHON_TARGET-ish setting on the system:
>
> $ grep PYTHON_TARGET /etc/portage/make.conf
> /etc/portage/package.use/*
> /etc/portage/make.conf:#PYTHON_TARGETS="python3_7 python2_7"
> /etc/portage/package.use/dizzy:#*/* PYTHON_TARGETS: python3_6 python3_7
> /etc/portage/package.use/dizzy~:#*/* PYTHON_TARGETS: python3_6 python3_7

There is, just not set by you. There is still the default setting, which
emerge --info will show you is 3.8.

> $ equery uses dev-python/pyyaml
> [ Legend : U - final flag setting for installation]
> [ : I - package is installed with flag ]
> [ Colors : set, unset ]
> * Found these USE flags for dev-python/pyyaml-5.4.1:
> U I
> - - examples : Install examples, usually source
> code
> + + libyaml : enable support for C implementation
> using libyaml
> - - python_targets_python3_7 : Build with Python 3.7
> + + python_targets_python3_8 : Build with Python 3.8
> - - python_targets_python3_9 : Build with Python 3.9
> - - test : Enable dependencies and/or
> preparations necessary to run tests (usually controlled by
> FEATURES=test but can be toggled
> independently) (ins)

libyaml is built for python 3.8 only, as that is the setting you have in
place.

> lembark@dizzy ~ $ eselect python list
> Available Python interpreters, in order of preference:
> [1] python3.9
> [2] python3.6
> [3] python3.8 (fallback)
> [4] python3.7 (fallback)
> [5] python2.7 (fallback)
>
> $ python3 --version;
> Python 3.9.1

But you have chosen a different default version of Python. That leaves
you two choices:

1) use eselect to set your default python to 3.8
2) Add python_39 to PYTHON_TARGETS
3) Explicitly call python38 in the shebang line of the affected script.


--
Neil Bothwick

QOTD:
The only easy way to tell a hamster from a gerbil is that the
gerbil has more dark meat.

On Sun, 7 Mar 2021 22:04:39 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> But you have chosen a different default version of Python. That leaves
> you two choices:
>
> 1) use eselect to set your default python to 3.8
> 2) Add python_39 to PYTHON_TARGETS
> 3) Explicitly call python38 in the shebang line of the affected
> script.

So, I go back and eselect 3.8.
I then try to perform some basic maintainence which fails for
lack of a python module I think is installed for python 3.8.

Q: Is there no way to have a consistent version of Python on
the system?

# eselect python list;
Available Python interpreters, in order of preference:
[1] python3.8
[2] python3.6
[3] python3.9
[4] python3.7 (fallback)
[5] python2.7 (fallback)


# emerge dev-python/chardet;

<snip>

writing byte-compilation script '/tmp/portage/dev-python/chardet-4.0.0/temp/tmp591yrh90.py'
* /usr/bin/python3.8 /tmp/portage/dev-python/chardet-4.0.0/temp/tmp591yrh90.py
removing /tmp/portage/dev-python/chardet-4.0.0/temp/tmp591yrh90.py
writing byte-compilation script '/tmp/portage/dev-python/chardet-4.0.0/temp/tmp9vcif_en.py'
* /usr/bin/python3.8 /tmp/portage/dev-python/chardet-4.0.0/temp/tmp9vcif_en.py
removing /tmp/portage/dev-python/chardet-4.0.0/temp/tmp9vcif_en.py

<snip>

>>> Installing (1 of 1) dev-python/chardet-4.0.0::gentoo
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

!!! existing preserved libs:
>>> package: dev-libs/icu-68.2
* - /usr/lib64/libicudata.so.67
* - /usr/lib64/libicudata.so.67.1
* - /usr/lib64/libicui18n.so.67
* - /usr/lib64/libicui18n.so.67.1
* used by /usr/bin/js60 (dev-lang/spidermonkey-60.5.2_p0-r4)
* used by /usr/lib64/libmozjs-60.so (dev-lang/spidermonkey-60.5.2_p0-r4)
* - /usr/lib64/libicuuc.so.67
* - /usr/lib64/libicuuc.so.67.1
* used by /usr/bin/js60 (dev-lang/spidermonkey-60.5.2_p0-r4)
* used by /usr/lib64/libmozjs-60.so (dev-lang/spidermonkey-60.5.2_p0-r4)
Use emerge @preserved-rebuild to rebuild packages using these libraries


* python3_8: running distutils-r1_run_phase distutils-r1_python_install_all


# $emerge @preserved-rebuild

These are the packages that would be merged, in order:

Calculating dependencies... done!

* emerge: there are no ebuilds to satisfy ">=dev-python/chardet-3.0.2[python_targets_python3_6(-),python_targets_python3_7(-),python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]".
<snip>

# emerge --search dev-python/chardet;

[ Results for search key : dev-python/chardet ]
Searching...

* dev-python/chardet
Latest version available: 4.0.0
Latest version installed: 4.0.0



# emerge --info dev-python/chardet;
* Portage 3.0.13 (python 3.8.7-final-0, default/linux/amd64/17.1, gcc-9.3.0, glibc-2.32-r3, 5.9.1-gentoo-af x86_64)
* dev-lang/python: 2.7.18-r6::gentoo, 3.6.12-r2::gentoo, 3.7.9-r2::gentoo, 3.8.7-r1::gentoo, 3.9.1-r1::gentoo
* USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 python3_8 (-pypy3) -python3_9"


See <https://pastebin.com/JbKXEptz> for details of --info.

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Sun, 07 Mar 2021 19:30:21 +0000
Michael <confabulate@kintzios.com> wrote:


> eselect python cleanup
> emerge --depclean -v -p
> emerge @preserved-rebuild -v -a

cleanup doesn't seem to change anything.
depcleand doesn't remove anything.
@preserved-rebuild failes due to lack of an already-installed
python library.

--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Sun, 7 Mar 2021 18:32:26 -0500, Steven Lembark wrote:

> > 1) use eselect to set your default python to 3.8
> > 2) Add python_39 to PYTHON_TARGETS
> > 3) Explicitly call python38 in the shebang line of the affected
> > script.
>
> So, I go back and eselect 3.8.
> I then try to perform some basic maintainence which fails for
> lack of a python module I think is installed for python 3.8.

If your system has been built entirely with PYTHON_TARGETS="python_38"
then all installed modules should be available.

> Q: Is there no way to have a consistent version of Python on
> the system?

Yes, make sure PYTHON_TARGETS and your chosen version of python match.


--
Neil Bothwick

Do Roman paramedics refer to IV's as "4's"?

On Sun, 7 Mar 2021 23:47:26 +0000, Neil Bothwick wrote:

> > So, I go back and eselect 3.8.
> > I then try to perform some basic maintainence which fails for
> > lack of a python module I think is installed for python 3.8.
>
> If your system has been built entirely with PYTHON_TARGETS="python3_8"
> then all installed modules should be available.
>
> > Q: Is there no way to have a consistent version of Python on
> > the system?
>
> Yes, make sure PYTHON_TARGETS and your chosen version of python match.

I forgot to add that PYTHON_TARGETS can include multiple versions, so the
sensible option in your situation may be to set it to "python3_8 python3_9".


--
Neil Bothwick

Sacred cows make great hamburgers.

> > Q: Is there no way to have a consistent version of Python on
> > the system?
>
> Yes, make sure PYTHON_TARGETS and your chosen version of python match.

Q: How do I know which verson of python is suitable?

I never deal with the language... last I saw was some news that
turn off the targets would be preferable. Is there some real
advantage to targets vs target (i.e., at this point is it reasonable
to just have a single target)?

I'm still not sure, however, why a module installed with python 3.8
would leave portage disfunctional if that version were selected.

Thanks


--
Steven Lembark
Workhorse Computing
lembark@wrkhors.com
+1 888 359 3508

On Mon, 8 Mar 2021 at 00:32, Steven Lembark <lembark@wrkhors.com> wrote:
> * emerge: there are no ebuilds to satisfy ">=dev-python/chardet-3.0.2[python_targets_python3_6(-),python_targets_python3_7(-),python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]".
> <snip>

If you can unsnip here and show more of the output, we could see what
package is causing this error. This error is telling you that
something in the snipped output is requiring dev-python/chardet to be
built with python targets matching that other package, and that
package seems to be using other targets than the default 3.8.

Since you've already mentioned that depclean doesn't remove anything,
do you have any package-specific python targets set that you've
forgotten about?
# grep python_targets /etc/portage/package.use/*

It seems to me very similar to other threads on this list where people
have older packages hanging back that creates problems because portage
can't remove them.

Regards,
Arve

On Sun, 7 Mar 2021 18:52:50 -0500, Steven Lembark wrote:

> > > Q: Is there no way to have a consistent version of Python on
> > > the system?
> >
> > Yes, make sure PYTHON_TARGETS and your chosen version of python
> > match.
>
> Q: How do I know which verson of python is suitable?
>
> I never deal with the language... last I saw was some news that
> turn off the targets would be preferable. Is there some real
> advantage to targets vs target (i.e., at this point is it reasonable
> to just have a single target)?

In that case, you had no reason to use eselect to switch away from the
default. Switch back to 3.8 with eselect and all should be well - at
least after an emerge -auDN @world

> I'm still not sure, however, why a module installed with python 3.8
> would leave portage disfunctional if that version were selected.

That does seem odd, were any dependent modules also installed for 3.8.


--
Neil Bothwick

Documentation: (n.) a novel sold with software, designed to entertain the
operator during episodes of bugs or glitches.

On Sat, 13 Mar 2021 at 18:23, Steven Lembark <lembark@wrkhors.com> wrote:
> > grep python_targets /etc/portage/package.use/*
>
> That was it: I never new that the python targets got stuck
> in the zz_autoconfigure file.
>
> Sanity check: Do I actually need to set the python target or
> python single target for the system to function?

Usually not, they have defaults that works most of the time. You
should really only set them for specific packages and specific
versions where you need it for something special.

Regards,
Arve