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 A03E91381F3 for ; Thu, 15 Nov 2012 21:43:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ACEE521C001; Thu, 15 Nov 2012 21:43:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0EA7B21C001 for ; Thu, 15 Nov 2012 21:43:17 +0000 (UTC) Received: from pomiocik.lan (87-205-58-131.adsl.inetia.pl [87.205.58.131]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E678A33D864; Thu, 15 Nov 2012 21:43:15 +0000 (UTC) Date: Thu, 15 Nov 2012 22:44:25 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-python@lists.gentoo.org Cc: python@gentoo.org Subject: [gentoo-python] Package supporting single implementation only -- auxiliary variable solution Message-ID: <20121115224425.5762484c@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; 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_/9OSI/eQJx/_S3Uatod6+b1N"; protocol="application/pgp-signature" X-Archives-Salt: 4c04754f-547c-4c72-9d46-3ca860b18ac6 X-Archives-Hash: 88e5d06452718b4ddd5de45bd58bab58 --Sig_/9OSI/eQJx/_S3Uatod6+b1N Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I am still thinking what would be the best way of handling packages which support being built for a single Python implementation only (like packages embedding Python and not being boost). A few shortcuts for the scope of this mail: SIP - package supporting being built for a single implementation only MIP - package supporting being built for multiple implementations Now, the problem with SIP is that they can support only one Python implementation at a time. I'd like to find a solution which: 1) would be the most user- and developer-friendly, 2) would be transparent and explicit (user has to know which implementation is actually used, and be able to switch it), 3) would not require different dependency atoms for dependencies which are SIP (i.e. the package just depends on another Python package, not caring whether it is SIP or MIP). So far, the solution of using REQUIRED_USE=3D'^^ ( python_targets... )' fulfilled 2) & 3). Sadly, it is hardly user-friendly because whenever user has more than one Python implementation in PYTHON_TARGETS, he needs to explicitly disable other flags for each package. Additionally, this means that if SIP becomes a MIP, user is unaware of that and still explicitly disables additional implementations. I could live with that if not the fact that the default PYTHON_TARGETS currently list two implementations. Therefore, not only a specific group but all our users would be forced to switch flags like that. Hopefully, there's one way we could achieve a bit of user-friendliness for most of the cases. If we introduced an auxiliary variable, let's call it PYTHON_SINGLE_TARGET for now, it could work. The eclass used for SIP: 1) adds PYTHON_SINGLE_TARGET flags (following PYTHON_COMPAT) to IUSE, 2) adds REQUIRED_USE=3D'^^ ( python_single_target... )', 3) adds REQUIRED_USE=3D'python_single_target...? ( python_targets... )', 4) replaces PYTHON_USEDEP with: 'python_targets...?,python_single_target...?(+)', 5) sets the variables based on PYTHON_SINGLE_TARGET in pkg_setup(). Therefore, users can explicitly use PYTHON_SINGLE_TARGET to choose the target which would be user for SIP while keeping the complete PYTHON_TARGETS for MIP. It's much more friendly. Thanks to EAPI4 USE defaults, the ${PYTHON_USEDEP} works fine both for MIP and SIP deps. For a MIP dep, the PYTHON_TARGETS are used as the real check. PYTHON_SINGLE_TARGET aren't there and they default to enabled, so the check passes. The REQUIRED_USE ensures that PYTHON_TARGETS contains PYTHON_SINGLE_TARGET. For a SIP dep, the PYTHON_SINGLE_TARGET is available and becomes relevant. In the corner case when PYTHON_SINGLE_TARGET for package A specifies an implementation which is not supported by package B, the PYTHON_SINGLE_TARGET check succeeds (missing flag =3D enabled) but the PYTHON_TARGETS check fails due to missing flag. Of course, a MIP would not be allowed to depend on a SIP. The profiles would specify a single default implementation from PYTHON_TARGETS as a default for PYTHON_SINGLE_TARGET. This will effectively hide the issue from most of our users. Those who set PYTHON_TARGETS explicitly may need to adjust the PYTHON_SINGLE_TARGET. Considering that it will be common to all SIPs, it's much more friendly than switching per-package. The only real issue unsolved is friendly solving of Py2/3 issues with SIPs. If user has PYTHON_SINGLE_TARGET=3Dpython2_7, SIP package supporting Python3 only (is there any?) would require explicit flag setting. I believe that's a corner case. It could be solved if we invented some kind of 'automatic USE defaults'. In that case, profiles wouldn't specify a default but instead portage would pick one based on REQUIRED_USE constraints and flag order. In other words: - user has PYTHON_TARGETS=3D'python2_7 python3_2', - package has PYTHON_COMPAT=3D( python{2_6,2_7} ), -> per-package PYTHON_TARGETS becomes 'python2_7', - REQUIRED_USE=3D'^^ ( pst2_6 pst2_7 ) pst2_6? ( py2_6 ) ...' -> portage tries pst2_6... --> py2_6 not set, REQUIRED_USE unsatisfied; -> portage tries pst2_7 --> py2_7 set, all ok. ---> PYTHON_SINGLE_TARGET=3Dpython2_7 But that's not really necessary right now, I think. To sum it up quickly, the aux variable solution: Advantages: - painless for most of our users, - explicit, transparent, - simple and matching SIP->SIP and SIP->MIP deps. Disadvantages: - a bit redundant, - does not solve the issue for py3-only SIP packages, - may require explicit action when changing PYTHON_TARGETS. What are your thoughts? --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/9OSI/eQJx/_S3Uatod6+b1N Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlClYjoACgkQfXuS5UK5QB22EwQAhhTwnFd+li7TNhz4Y+8+UWXf Dz8a96KDKHcDOh3BF6yA86hztufwUe+3BZzzT/k6KTmxJHr2ouGT0njyepxZG0DG FAZkKCImJedi532habYiyGESxBpanw3u6Ib9fAryi0+5cAYZS8mI3i9Rv3xr8hW8 S6uqWvsDG9vrLM2jjdM= =lQBX -----END PGP SIGNATURE----- --Sig_/9OSI/eQJx/_S3Uatod6+b1N--