From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 39DBF138A1F for ; Fri, 11 Apr 2014 15:43:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5B30FE09A7; Fri, 11 Apr 2014 15:43:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6AF46E09A7 for ; Fri, 11 Apr 2014 15:43:19 +0000 (UTC) Received: from pomiot.lan (77-254-69-105.adsl.inetia.pl [77.254.69.105]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 864EA33FFF2; Fri, 11 Apr 2014 15:43:16 +0000 (UTC) Date: Fri, 11 Apr 2014 17:43:02 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: gentoo-python Cc: python@gentoo.org, jlec@gentoo.org, gnome@gentoo.org Subject: [gentoo-python] Mixing python-any-r1 (e.g. waf-utils.eclass) and python-single-r1 in a single ebuild Message-ID: <20140411174302.5c63fdba@pomiot.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Discussions centering around the Python ecosystem in Gentoo Linux X-BeenThere: gentoo-python@gentoo.org X-BeenThere: gentoo-python@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/NNJ8U+sW/sCH0XoWPPhAx6N"; protocol="application/pgp-signature" X-Archives-Salt: 965a6be9-2d88-4b56-afdc-242ea0d3319c X-Archives-Hash: 786834e069c7e34846b751427c0aea53 --Sig_/NNJ8U+sW/sCH0XoWPPhAx6N Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hello, all. If I recall correctly, jlec lately mentioned he'd like to use python-any-r1 and python-single-r1. A particularly inevitable use case for this would be ebuilds using waf, so I'll use that as an example. The idea is pretty simple. Since the ebuilds in question use waf that is in Python, the waf-utils.eclass inherits python-any-r1. However, some of the ebuilds may install Python modules as well, and that asks for python-single-r1. So the issue is how to make the two work together. Possible solution: hierarchical eclass overrides ------------------------------------------------ Idea: if both python-any-r1 and python-single-r1 are inherited, the latter transparently overrides the former. More specifically, implementation selected for python-single-r1 is used for code designed for python-any-r1. Details: 1. PYTHON_COMPAT is declared before the inherits, so it should be always set by ebuild. If we feel like the eclass needs to provide the default, it may only do so if ebuild doesn't set its own PYTHON_COMPAT. The eclass may also need to check ebuild's PYTHON_COMPAT for conflicts with own supported impls (and die in that case). 2. PYTHON_REQ_USE likewise. The eclass may append to it (but careful with that). 3. ${PYTHON_DEPS}: a. if python-single-r1 is inherited before python-any-r1 (waf-utils), PYTHON_DEPS is set by the former and the latter doesn't change it. Both waf-utils and the ebuild add PYTHON_DEPS, so the same deps get added twice but there's no functional difference from python-single-r1, b. if python-single-r1 is inherited after waf-utils, the latter adds dependency based on python-any-r1 and then the ebuild adds another based on python-single-r1. With a bit of luck or good programming, everything works fine. Worst case, additional version of Python may get pulled build-time as a result of any-of dep. 4. python_setup() gets exported (overriden) by python-single-r1. Since it is called after the complete inherit chain, the correct version is used. 5. python-any-r1_pkg_setup() just calls python-single-r1_pkg_setup(). 6. python_check_deps() is not used. 7. python_gen_any_dep() is an issue I don't know how to solve: a. if python-single-r1 is inherited before python-any-r1, it could override it so that it generates just a single dependency matching the syntax used for python-single-r1, b. but if waf-utils is inherited first, the dep strings will be generated before python-single-r1 is inherited, c. possibly we could just ban python_gen_any_dep() and make it export magical variable that will cause python-single-r1 inherit to die. Your thoughts? --=20 Best regards, Micha=B3 G=F3rny --Sig_/NNJ8U+sW/sCH0XoWPPhAx6N Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJTSA2KXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOvekP/ifo2IsqIZfrDk8/d/54Nxmt COVYrh8kQozYQos7IdJSOrx4G1ZvBDqvz69Fp5te8TSwA8hXBZcwv7deICN5/2X9 50J/qh2Jw2HZhuhvbq++JXgbWslgmvyUjg5sP/hEk9IsAb/Ypu3dvzMtuyDtBRfc J90AEsQXtsL9c/A2VB+MP3zr35gZaNuFD8N8wDwUeQSRbsdzScGSn4XMHCJOL1nX kdnivwUW5P6ncln7EN2CcXuUORRFc6NMQ9tEw+0DKTebh53xCGK2NgLdYBFp8H0d CHQxNg7oL1xL9OS5b+sDYFzMeqNi1Ugm9a2T9T67SC/1vRkJ7C4AHChTirXF36UU hKUiwavuz6ywetYdfsPOpSZqUJUg7FtAW3+Lh3th5YFeX18L4MKETyJwGN9m1xSP TeC4ttCJDDKV59FF+hD4iHpC+WrSJmKTRnkgalOJwJLQS9P7dbzlr0dCwKdcqZos cKhvzbZCPbMF0Ayq3oghrRcN5wJr0rr7e6MTnLj9o6Ww23ZqtVuMrm79k5YpAwka AiGE3jQAjFzxy3GTfPwISpVeWM7PJjY0H7aj6SsEc7dtjryoSVB1R2xQ9F8VYcUD HJWDMCTXP5tM8PU/IHYAbWTNhEIpJwLvliZNBXt2OkDNidzF8HuJqlxcjekbYfc3 9Uwo8kU09ZpOx2DIvu4S =lLLC -----END PGP SIGNATURE----- --Sig_/NNJ8U+sW/sCH0XoWPPhAx6N--