From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B3F04138010 for ; Tue, 25 Sep 2012 21:59:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B226A21C19D; Tue, 25 Sep 2012 21:59:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E29F321C19D for ; Tue, 25 Sep 2012 21:59:19 +0000 (UTC) Received: from pomiocik.lan (77-253-194-73.adsl.inetia.pl [77.253.194.73]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id C359D33D149; Tue, 25 Sep 2012 21:59:17 +0000 (UTC) Date: Tue, 25 Sep 2012 23:59:18 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-python@lists.gentoo.org Cc: python@gentoo.org, hasufell@gentoo.org Subject: [gentoo-python] USE flag dependencies on Python implementation Message-ID: <20120925235918.3a1c7871@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.12; 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-SHA256; boundary="Sig_/N0.rYeA5wA/V0jFBxDaFBEq"; protocol="application/pgp-signature" X-Archives-Salt: 30a7137d-d69c-42c3-8f0c-82a0b2282f3a X-Archives-Hash: 3f7fdb9129002d7ac21afff3940726c0 --Sig_/N0.rYeA5wA/V0jFBxDaFBEq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, The one of the worst problems which we are about to try to solve is how packages should depend on particular features of Python implementation. With three different implementations, this seems to become a bit problematic. First of all, I'd like to note that different Python implementations have different USE flags (and sometimes they even change by version). I've tried to find all the flags and put them in a nicely readable matrix here: http://wiki.gentoo.org/wiki/Python/Implementation_USE_flags Sadly, jython is mostly black magic to me and a few other flags like 'ipv6' and 'threads' which can't be really deduced from deps as well. I'd really appreciate if someone could fill the table completely. The idea there is simple. If something is marked as 'flag', then a particular feature is optional and enabled via the listed flag. If it's '+', then it's always on. If it's '-', then it's not implemented at all. Looking at it now, there isn't yet a single flag which would be portable to all Python implementations. That rises the question on how packages should depend on features of the Python implementations. Secondly, I'd like you to answer the following questions which will determine which solutions are possible at all: Let's assume than an ebuild has optional ncurses support via IUSE=3Dncurses, and it requires ncurses module in Python. Not all Python implementations support ncurses. Without the USE flag, the package is portable to all implementations. 1. Now, the user has enabled all Python implementations, and USE=3Dncurses. What should happen? a) REQUIRED_USE bailing out -- user is explicitly forced to disable some of the implementations locally or IUSE=3Dncurses; it is clear to him what happened; b) the package is built with implementations supporting ncurses only -- no explicit failure for user but then he is surprised that the package wasn't actually built for all impls, and he doesn't even know what happened. We could ewarn him, but that's a bit like reimplementing REQUIRED_USE. Feel free to suggest a c). 2. Now, the user has enabled Jython only (the impl. without ncurses) and USE=3Dncurses. What should happen? If you have chosen a) previously, REQUIRED_USE is perfectly fine here as well. If you have chosen b) instead, then what now? We are either installing an empty package or having an inconsistent behavior. Now, let's get to the actual possible solutions for new python eclasses. 1/ separate USE-dep variables for each implementation This is the solution suggested by hasufell: PYTHON_USEDEP=3D"ncurses?" PYPY_USEDEP=3D"ncurses?" JYTHON_USEDEP=3D # err, what exactly here? The advantage is that... errr... it works? Sadly, I'm a bit afraid it's like throwing a bunch of screws on the developer and saying 'now figure out what they may be useful for'. 2/ a single magical variable as in python.eclass Well, it probably works... somehow. The more features we want, the more code we have to write. And reinvent the wheel, and remember not to lose compatibility when adding new features. I'd really like to avoid even thinking about this. 3/ a single USE-dependency string common to all implementations Something like in my proposition of python-r1.eclass. Either: PYTHON_USEDEP=3D'ncurses?' REQUIRED_USE=3D'ncurses? ( !python_targets.... )' or: PYTHON_USEDEP=3D'ncurses?(-)' The latter being probably incorrect wrt PMS. 4/ a virtuals for Python features Instead of setting USE-dependency strings directly, invent a few virtuals like: virtual/python-ncurses: python_targets_python2_7? ( dev-lang/python:2.7[ncurses] ) ... And then let ebuilds depend on them like: RDEPEND=3D"virtual/python-ncurses[$PYTHON_USEDEP]" This solution introduces magic similar to one in 2/ while keeping it free of scary code. Not sure if it's really useful considering the REQUIRED_USE problem. We can make the virtuals add blockers for python implementations being enabled without the feature. But I'm not sure if it's semantically correct, i.e.: dev-python/foo[python_targets_jython2_5]: dev-java/jython:2.5 virtual/python-ncurses[python_targets_jython2_5]: !dev-java/jython:2.5 This just looks wrong ;). And it will require user to unnecessarily change flags on virtual itself. What are your opinions, ideas? --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/N0.rYeA5wA/V0jFBxDaFBEq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlBiKTsACgkQfXuS5UK5QB3KXAQAkBYNjXW7+lhih7FpfcI27Shn UXrJnCAyBJownky1XQgsYHBlCiVJZw3nBRJ1TmsmKkEr0SWX/jhV7mOKKrXYJ1hr /yz/GRWABF82Ek3hH6dQfidh689/AG2UVYKE7XUvClDDXszrirTWN/Z0Qg231ljP uOmVkVzwqWaJtvV5NIw= =CSzo -----END PGP SIGNATURE----- --Sig_/N0.rYeA5wA/V0jFBxDaFBEq--