python_targets dependency conflict for pygments

jagdpanther · l33t Joined: 22 Nov 2003 Posts: 743

Starting yesterday after an "emerge --sync" and another "emerge --sync" today, portage is returning a "skipped due to a dependency conflict" for pygments:

UlFie · Posted: Mon May 04, 2020 9:53 pm Post subject:

How about trying this the other way round, i.e. -python2_7 on the PYTHON_TARGETS for docutils?

Anon-E-moose · Posted: Mon May 04, 2020 9:59 pm Post subject:

Take off the 2.7 for docutils.

They both emerged for me this morning without any problems. (I had already blocked py2.7 stuff though)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

jagdpanther · l33t Joined: 22 Nov 2003 Posts: 743

I added the following line to /etc/portage/package.use/gentoo:
dev-python/docutils PYTHON_TARGETS: -python2_7

Now I have two dependency conflicts. docutils with just python3_6 has an issue as dev-python/m2r

jagdpanther · l33t Joined: 22 Nov 2003 Posts: 743

Another strange development:
On my 2nd Gentoo system I just ran

Anon-E-moose · Posted: Mon May 04, 2020 11:00 pm Post subject:

jagdpanther · l33t Joined: 22 Nov 2003 Posts: 743

Anon-E-moose:

Thanks for the advice. I guess I'll need to do this and will try tomorrow.
One question:
What is the difference between your suggested modifications to
/etc/portage/profile/use.mask and /etc/portage/profile/package.use.mask
VS the suggestion to change things in /etc/portage/package.use (not profile) mentioned in
the eselect news item titled "Python 2.7 went EOL" ?

hagar-dunor · n00b Joined: 26 Apr 2012 Posts: 39

Joining the "me too" bandwagon, got this conflict on all my installs.
It happens on all related things being "stable" from what I can tell, so it's not up to the user to tweak around?

Anon-E-moose · Posted: Tue May 05, 2020 2:03 pm Post subject:

Anon-E-moose · Posted: Tue May 05, 2020 2:06 pm Post subject:

The reason these problem are cropping up (MO) is that they're transitioning away from 2.7 and some stable things haven't been properly updated.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

hagar-dunor · n00b Joined: 26 Apr 2012 Posts: 39

From what I see in the pygments 2.5.2 ebuild:
PYTHON_COMPAT=( python2_7 python3_{6,7,8} pypy3 )

and in pygments 2.6.1 ebuild
PYTHON_COMPAT=( python3_{6,7,8} pypy3 )

Compatibility with python 2.7 has been dropped. However docutils, which depends on pygments has
PYTHON_COMPAT=( python{2_7,3_{6,7,8}} pypy3 )

So logic tends to say that pygments 2.6.1 dropped python 2.7 compat by mistake unless I don't understand EAPI which is more than likely.

jagdpanther · l33t Joined: 22 Nov 2003 Posts: 743

Anon-E-moose:

Your note about not using python2_7 seems much easier than I thought it would be to implement. Thank you. (Portage is about to re-emerge about 100 packages and add a few.)
Here is all I had to add to my new /etc/portage/package.use/python file to get a 'clean' 'emerge --update --deep --newuse --with-bdeps=y @world -p'
This does solve my original issue with pygments.

Note: the exceptions will probably be different for anyone else looking at this.

hagar-dunor · n00b Joined: 26 Apr 2012 Posts: 39

Even if this goes beyond topic, this discussion actually helped me getting closer to removing python 2.7 and 3.6

I've put this eventually into /etc/portage/package.use/python:

Anon-E-moose · Posted: Wed May 06, 2020 1:01 pm Post subject:

jagdpanther · l33t Joined: 22 Nov 2003 Posts: 743

Anon-E-moose · Posted: Wed May 06, 2020 6:47 pm Post subject:

I assume (yeah, I know :lol:

) that they will do something similar to numpy, but that's a wild ass guess. How easy to implement and whether they will *shrugs*
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

Mr Bonhomme · n00b Joined: 03 Mar 2003 Posts: 30

If it can help, to solve theses dependencies, I added this to /etc/portage/package.mask/various:

sheep204 · n00b Joined: 28 Dec 2005 Posts: 31

re-emerge m2r and docutils with PYTHON_TARGETS: -python2_7

araxon · Tux's lil' helper Joined: 25 May 2011 Posts: 83

I have the same problem. I don't have PYTHON_TARGETS or PYTHON_SINGLE_TARGET defined anywhere.

I really don't care about python versions. The only reason for python existing on my servers is the bloody emerge is written in it. What can I do to make it happy again?

samychow · n00b Joined: 30 Oct 2010 Posts: 4

I have had this same problem as well ever since following the instructions from a couple months ago about transitioning to python 2.7 and 3.6. I thought it would eventually get corrected by a change to an ebuild but it hasn't yet.

I am now seeing there is a bug report about it: https://bugs.gentoo.org/722762 . I followed the instructions of someone there to modify the appropriate package.use file to reflect the following:

Hu · Administrator Joined: 06 Mar 2007 Posts: 21842

This is not a result of you following the migration instructions. As you note, this is dev-python/docutils-0.16 still supports Python 2.7 but it's dependency dev-python/pygments-2.6.1 doesn't -- dependency conflict, and is caused by the Gentoo maintainers removing Python 2.7 support in the wrong order. Pygments should have retained its 2.7 support until docutils dropped support for 2.7, but did not. You can ignore this message, or eliminate it by explicitly disabling Python 2.7 support for docutils as you did.

proteusx · Guru Joined: 21 Jan 2008 Posts: 338

My solution was to move pygments-2.6.1.ebuild to my local overlay and modify the PYTHON_COMPAT line to add python2 support:

asturm · Developer Joined: 05 Apr 2007 Posts: 8956

It's just a warning, not a problem.

asturm · Developer Joined: 05 Apr 2007 Posts: 8956

Hu · Administrator Joined: 06 Mar 2007 Posts: 21842

I was referring to the ebuilds, as that is what the Gentoo maintainers control. The maintainers could have removed Python 2.7 from the docutils ebuild before committing the pygments-2.6.1 ebuild that lacks Python 2.7 in PYTHON_COMPAT. I am actually a bit surprised that repoman did not scream long and loud about that, as I thought it was very zealous about dependency checks like that.