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 8A21A138010 for ; Sun, 9 Sep 2012 15:22:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1E92EE0478; Sun, 9 Sep 2012 15:22:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E488CE0478 for ; Sun, 9 Sep 2012 15:21:59 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 1D92833C27B for ; Sun, 9 Sep 2012 15:21:58 +0000 (UTC) Received: by wgbfm10 with SMTP id fm10so808931wgb.10 for ; Sun, 09 Sep 2012 08:21:56 -0700 (PDT) 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 Received: by 10.180.82.164 with SMTP id j4mr11013777wiy.18.1347204116351; Sun, 09 Sep 2012 08:21:56 -0700 (PDT) Received: by 10.223.100.10 with HTTP; Sun, 9 Sep 2012 08:21:56 -0700 (PDT) In-Reply-To: <20120909103337.2eb72f49@pomiocik.lan> References: <20120909103337.2eb72f49@pomiocik.lan> Date: Sun, 9 Sep 2012 11:21:56 -0400 Message-ID: Subject: Re: [gentoo-python] Concept for optional Python dependency and USE-flag deps in p-d-ng From: Mike Gilbert To: gentoo-python@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f4b66cc2-922b-4516-bf16-bc35a1ba77bd X-Archives-Hash: b96ddfb2419875583ead35e73fc92d34 On Sun, Sep 9, 2012 at 4:33 AM, Micha=C5=82 G=C3=B3rny = wrote: > Hello, > > After some thinking, I think I found an optimal solution to > implementing various kinds of Python dependencies and PYTHON_USE_WITH*. > > As a note, all variable names are dirty and not official. Feel free to > suggest better ones. > > 1. Add a user-defined variable PYTHON_USE. If user needed any specific > flags from a Python dependency, he can set the USE dependency string > there. The string will have to follow the general rules for USE > dependencies and be correct for every Python implementation specified > in PYTHON_COMPAT (this may require USE defaults). For example: > > PYTHON_USE=3D"ncurses,sqlite" > > 2. Add a eclass-defined variable PYTHON_DEPEND. It will be always > exported, and contain a dependency string created using PYTHON_COMPAT > and PYTHON_USE -- the most simple and most common one, e.g.: > > PYTHON_DEPEND=3D" > python_targets_pythonX_Y? > ( dev-python/python:X.Y[ncurses,sqlite] ) > " > > 3. By default, just append PYTHON_DEPEND to DEPEND and RDEPEND. Provide > an option to disable that. If user wants optional Python, he can > disable it and use ${PYTHON_DEPEND} in his own *DEPEND code. (we could > also provide a quick switch to add 'python? ( )' or '$USEFLAG? ( )'). > I like the idea of the PYTHON_DEPEND variable and the option to disable its addition to DEPEND and RDEPEND. That makes it simple to control for packages which only need python for building, for example. I don't think we really need the switch you mention for controlling optional python dependencies, but I guess it couldn't hurt. > 4. Finally, provide a general, parametrized dependency generator > function which will be useful in all the remaining non-common cases > which can't be handled sanely by any other solution. > Sounds good to me. We should hash out exactly what parameters it would take; hopefully we can make it flexible enough to deal with changes in dependency atoms in future EAPIs. As I interpret your example, your hypothetical function takes a list of use flags as $1, and the rest of the parameters are python targets. Maybe we should put the use flag list behind a switch? I'm mainly thinking of scenarios where various python implementations support different use flags.