Sanity check, PYTHON_ TARGETS, SINGLE_TARGET: -python2_7

[pjp]

EDIT: I recommend starting with Ant. P's solution. I've switched to a modified version of that solution, but only for transition.



Until now, I have let the profile determine what the targets ought to be. I haven't been able to find much that addresses the dangers of manipulating the targets. In a general sense, I get it.

Project:Python/PYTHON TARGETS helped me guess the "-python2_7" usage.

From emerge --info:

[fcl]

Why not go with a whitelist instead?

[pjp]

"-* python3_5" forces only 3_5, doesn't it?

My thinking with -python2_7 was that other choices would be addressed by Portage.

I guess I'm just uncertain down which path lies more effort to maintain. And it shouldn't be too difficult to switch or undo.
_________________
Quis separabit? Quo animo?

[Ant P.]

I've been doing something slightly more extreme - whitelisting all use of python. I started doing this after the 3.4->3.5 transition because I saw most of the changes were in packages with USE="-python" on them already, thus useless. If I'm going to be forced to rebuild them all anyway, might as well make sure it doesn't happen again.

Here's the package.use (it used to be much longer, but I uninstalled chromium):

[pjp]

Hmm. Thanks. At least I'm not doing something horribly scary :)

I'm guessing Portage will complain if something needs, in your example, a python newer than 3_6?

What about knowing when newer targets become available? Do you just grep in profiles?


Thanks to both of you for the feedback.
_________________
Quis separabit? Quo animo?

[Hu]

I had considered doing something like Ant P. describes, because I too noticed the silliness of a package that respects USE=-python to completely omit all Python support, but still wanting to rebuild to change to a different Python target that it would then not use, due to USE=-python. Fixing this would require some syntax extension in the ebuild so that the ebuild could declare that USE=-foo implies that USE=bar is ignored, so no rebuild is required to add/remove bar if foo is unset. Hypothetically, it could be expressed as:

[pjp]

Maybe one of the developers is experiencing the same situation and has it on their shortlist :)

Thanks for the --verbose reminder. I normally didn't pay attention to the targets since I wasn't intervening. And it does seem to be there.

[Ant P.]

[pjp]

[pjp]

As I anticipated, my initial solution didn't take long before it became too brittle, so I've migrated to a modified / transitional form of Ant. P's solution.

[mv]

[Anon-E-moose]

In my case I wanted to block everything not python 2.7 while allowing one version of python 3 in, so in make.conf
PYTHON_TARGETS="python2_7"
PYTHON_SINGLE_TARGET="python2_7"

In package.mask block those python version(s) I don't ever want
dev-lang/python:3.3
dev-lang/python:3.4
dev-lang/python:3.5

In package.use these are the exceptions
dev-python/certifi python_targets_python3_6
dev-python/setuptools python_targets_python3_6
dev-util/meson python_targets_python3_6

I could just as easily have made python 3.6 the default while allowing a few python2 packages.
And either way there is some editing of package.use

Edit to add: and I ignore all requests to rebuild (no New use) because of changed "python" flags (whether adding or deleting)
as I figure that the next upgrade of whatever package will pick that up.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland