Gentoo Archives: gentoo-python

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev-announce <gentoo-dev-announce@l.g.o>
Cc: gentoo-python <gentoo-python@l.g.o>
Subject: [gentoo-python] Updates from Python team: python.eclass gone, gpyutils updates, incoming PYTHON_SINGLE_TARGET change
Date: Mon, 17 Apr 2017 20:39:43
Hi, everyone.

Here's a quick summary of the recent events in the Python ecosystem
in Gentoo, and quick note of what's to come.

python.eclass is gone, next things to come

As you probably learned already, python.eclass and distutils.eclass were
removed almost a month ago. This concluded a long effort of many
developers; once again, I would like to thank all of them for their help
and continued support.

With python.eclass gone, there are still many things to do. A few years
ago, Arfrever has been filing bugs requesting developers to improve
the use of python.eclass in their ebuilds -- today, we need to ask
developers to improve their use of python-r1.

The most important tasks at the moment are:

a. working on improving test suite statuses of Python packages -- good
and reliable test suites make all other work much easier;

b. working on porting Python packages to newer versions of CPython 3.5
and 3.6 -- we really ought to stabilize at least 3.5 soon;

c. fixing common mistakes in using python-r1 -- missing REQUIRED_USE,
dependencies, partial USE conditionals;

d. converting the few remaining packages that depend on python directly
to use one of the eclasses.

gpyutils report updates

With the most of python-r1 migration done, I've changed the reports
generated by gpyutils a fair bit. I've removed the verbose (and slow to
generate) reports for conversions, and killed the progress bars (they
were 100% anyway, except for python-any-r1 candidates).

The gpy-upgrade-impl reports for python3.6 were added. The upgrade
reports now include:
  packages that support 3.4 but not 3.5
  (preferably try 3.6 as well)
  packages that need newer version stabilized for 3.5 support
  packages that support 3.5 but not 3.6
  packages that need newer version stabilized for 3.6 support

Aside to those, two important reports were added recently. The first one
detects and reports common mistakes in python-r1&co ebuilds. The other
one provides a fast listing of all packages that need porting to python-
r1&co (i.e. depend on python directly).
  packages having common missing metadata bits
  packages to port to python-r1&co
  (note that python-any-r1 classification is usually wrong here,
   and python-single-r1 should be used instead)

While the former set of reports is mostly useful to Python team,
the latter set is useful to all developers. Especially with missing-
meta, we'd appreciate more developers fixing their own packages without
us having to file hundreds of bugs.

One-of-py2 + one-of-py3 unreliable, switching to single-r1

In other news, we've finally decided to abandon most of the effort to
support packages that explicitly provides support for one version of
python2 and one version of python3 in plugin systems. Two major cases of
this were libpeas (GNOME plugin thingy) and vim.

While technically possible to support those use cases, it proved very
difficult and unreliable for developers, both downstream and upstream,
and unfriendly to our users.

The GNOME team has already approved the changes for libpeas, and the new
~arch version supports python3 only, via python-single-r1. I will be
discussing converting vim to python-single-r1 soon.

PYTHON_SINGLE_TARGET changing to python-3

Last but not least, soap has been working a lot lately to make it
possible to finally switch PYTHON_SINGLE_TARGET to python3. The main
goal is to make it easier to support the growing number of packages that
no longer support python2 (esp. around GNOME).

Having to support multiple python3 targets, and at the same time having
only one python2_7 (and sometimes pypy) of python2 to support, it proves
better long-term to just default to the current version of python3.x via
PYTHON_SINGLE_TARGET, and add necessary package.use adjustments to
the few packages that support 2.7+pypy, than the other way around.

The current changes can be seen on the following pull request:

Best regards,
Michał Górny


File name MIME type
signature.asc application/pgp-signature