{"id":1090,"date":"2020-02-10T08:39:03","date_gmt":"2020-02-10T07:39:03","guid":{"rendered":"http:\/\/blogs.gentoo.org\/mgorny\/?p=1090"},"modified":"2020-02-21T11:29:42","modified_gmt":"2020-02-21T10:29:42","slug":"no-more-python_targets-in-single-r1","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2020\/02\/10\/no-more-python_targets-in-single-r1\/","title":{"rendered":"No more PYTHON_TARGETS in single-r1"},"content":{"rendered":"

Since its inception in 2012, python-single-r1 has been haunting users with two sets of USE flags: PYTHON_TARGETS<\/kbd> and PYTHON_SINGLE_TARGET<\/kbd>. While this initially seemed a necessary part of the grand design, today I know we could have done better. Today this chymera is disappearing for real, and python-single-r1 are going to use PYTHON_SINGLE_TARGET<\/kbd> flags only.<\/p>\n

I would like to take this opportunity to explain why the eclass has been designed this way in the first place, and what has been done to change that.
\n<\/p>\n

Why PYTHON_SINGLE_TARGET?<\/h2>\n

Why did we need a second variable in the first place? After all, we could probably get away with using PYTHON_TARGETS<\/kbd> everywhere, and adding an appropriate REQUIRED_USE<\/kbd> constraint.<\/p>\n

Back in the day we have established that for users’ convenience we need to default to enabling one version of Python 2 and one version of Python 3. If we enabled only one of them, the users would end up having to enable the other for a lot of packages. On the other had, if we combined both with using PT for single-r1 packages, the users would have to disable<\/em> the extra implementation for a lot of them. Neither option was good.<\/p>\n

The primary purpose of PYTHON_SINGLE_TARGET<\/kbd> was to provide a parallel sensible setting for those packages. It was not only to make the default work out of the box but also to let users change it in one step.<\/p>\n

Today, with the demise of Python 2 and the effort to remove Python 2 from default PT, it may seem less important to keep the distinction. Nevertheless, a number of developers and at least some users keep multiple versions of Python in PT to test their packages. Having PST is still helpful to them.<\/p>\n

Why additional PYTHON_TARGETS then?<\/h2>\n

PST is only half of the story. What I explained above does not justify having PYTHON_TARGETS<\/kbd> on those packages as well, and a REQUIRED_USE constraint to make them superset of enabled PST. Why did we need to have two flag sets then?<\/p>\n

The answer is: PYTHON_USEDEP<\/kbd>. The initial design goal was that both python-r1 eclasses would use the same approach to declaring USE dependencies between packages. This also meant that this variable must work alike on dependencies that are multi-impl and single-r1 packages. In the end, this meant a gross hack.<\/p>\n

Without getting into details, the currently available USE dependency syntax does not permit directly depending on PT flags based on PST-based conditions. This needs to be done using the more verbose expanded syntax:<\/p>\n

pst2_7? ( foo[pt2_7] )\r\npst3_7? ( foo[pt3_7] )<\/code><\/pre>\n
While this was doable back in the day, it was not possible with PYTHON_USEDEP<\/kbd>-based approach.  Hence, all single-r1 packages gained additional set of flags merely to construct dependencies conveniently.<\/p>\n
What is the problem with that?<\/h2>\n
I suppose some of you see the problem already.  Nevertheless, let’s list them explicitly.<\/p>\n
Firstly, enabling additional implementations is inconvenient.  Whenever you need to do that, you need to add both<\/em> PST and PT flags.<\/p>\n
Secondly, the PT flags are entirely redundant and meaningless for the package in question.  Whenever your value of PT changes, all single-r1 packages trigger rebuilds even if their PST value stays the same.<\/p>\n
Thirdly, the PT flags overspecify<\/em> dependencies.  If your PT flags specify multiple implementations (which is normally the case), all dependencies will also have to be built for those interpreters even though PST requires only one of them.<\/p>\n
The solution<\/h2>\n
The user-visible part of the solution is that PYTHON_TARGETS<\/kbd> are disappearing from single-r1 packages.  From now on, only PYTHON_SINGLE_TARGET<\/kbd> will be necessary.  Furthermore, PT enforcement on dependencies (if necessary) will be limited to the single implementation selected by PST rather than all of PT.<\/p>\n
The developer-oriented part is that PYTHON_USEDEP<\/kbd> is no longer valid in single-r1 packages.  Instead, PYTHON_SINGLE_USEDEP<\/kbd> is provided for dependencies on other single-r1 packages, and PYTHON_MULTI_USEDEP<\/kbd> placeholder is used for multi-impl packages.  The former is available as a global variable, the latter only as a placeholder in python_gen_cond_dep<\/kbd> (the name is a bit of misnomer now but I’ve decided not to introduce additional function).<\/p>\n
All existing uses have been converted, and the eclasses will now fail if someone tries to use the old logic.  The conversion of existing ebuilds is rather simple:<\/p>\n
    \n
  1. Replace all ${PYTHON_USEDEP}<\/kbd>s with ${PYTHON_SINGLE_USEDEP}<\/kbd> when the dep is single-r1, or with ${PYTHON_MULTI_USEDEP}<\/kbd> otherwise.<\/li>\n
  2. Wrap all dependencies containing ${PYTHON_MULTI_USEDEP}<\/kbd> in a python_gen_cond_dep<\/kbd>.  Remember that the variable must be a literal placeholder, i.e. use single quotes.<\/li>\n<\/ol>\n
    An example of the new logic follows:<\/p>\n
    RDEPEND=\"\r\n  dev-libs\/libfoo[python,${PYTHON_SINGLE_USEDEP}]\r\n  $(python_gen_cond_dep '\r\n    dev-python\/foo[${PYTHON_MULTI_USEDEP}]\r\n    dev-python\/bar[${PYTHON_MULTI_USEDEP}]\r\n  ')\r\n\"<\/code><\/pre>\n
    If you get the dependency type wrong, repoman\/pkgcheck will complain about bad dependency.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Since its inception in 2012, python-single-r1 has been haunting users with two sets of USE flags: PYTHON_TARGETS and PYTHON_SINGLE_TARGET. While this initially seemed a necessary part of the grand design, today I know we could have done better. Today this chymera is disappearing for real, and python-single-r1 are going to use PYTHON_SINGLE_TARGET flags only. I would like to take this opportunity to explain … Continue reading “No more PYTHON_TARGETS in single-r1”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[11],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/1090"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=1090"}],"version-history":[{"count":5,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/1090\/revisions"}],"predecessor-version":[{"id":1101,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/1090\/revisions\/1101"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=1090"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=1090"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=1090"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}