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 A6636138010 for ; Thu, 25 Oct 2012 21:25:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03BB721C026; Thu, 25 Oct 2012 21:25:48 +0000 (UTC) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 6834821C026 for ; Thu, 25 Oct 2012 21:25:48 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id j6so2104952oag.40 for ; Thu, 25 Oct 2012 14:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CszMlse51KNFTFsji72c3DO2i4tPt7Y06TYEHu3nmRU=; b=V4NMDsT4MIYrgVhDUHtHzgDN2FEPe+MJofgnCzkIa733q7eELyDyMfLOaKh6pDe6nr 5/xF32tHEsLE/3szugmOZOpsDGr78a+NdxgkcqI30DWpMVt7RpeEUX06Rlr3oOdaP2wH 6DyyXteovutCrOdt7FXo8JmqRumw5StQUZucT57dkl/l7h357VF29aJmBD2LZxXz9F/d eyilw3FIWqCFEbLj1dv6pWz0vUBk7nm6iB2tnOd7nomrBUdzBbBJHHFSX7yeKLm2Tjtk RSyOu01cWaiNLwfG0BEGXi5jb1kvHhHsUG+L2Ifd+TFs4o2AiPjgQym+QhIGyA6GQVHs r3zg== 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.60.172.236 with SMTP id bf12mr17741517oec.23.1351200347837; Thu, 25 Oct 2012 14:25:47 -0700 (PDT) Sender: neurogeekster@gmail.com Received: by 10.182.38.41 with HTTP; Thu, 25 Oct 2012 14:25:47 -0700 (PDT) In-Reply-To: References: <20121023235808.48cc6d9d@pomiocik.lan> Date: Thu, 25 Oct 2012 17:25:47 -0400 X-Google-Sender-Auth: G4plm9Q7YpWTI65k0CKnkv5msY0 Message-ID: Subject: [gentoo-python] Re: Handling packages not supporting multiple Python implementations From: "Jesus Rivero (Neurogeek)" To: Mike Gilbert Cc: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , gentoo-python@lists.gentoo.org, python@gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 30075145-b983-4d2e-a914-1bba8d52607c X-Archives-Hash: ab342c794a7211f90e8866cdcbb124c1 On Thu, Oct 25, 2012 at 5:00 PM, Mike Gilbert wrote: > On Tue, Oct 23, 2012 at 5:58 PM, Micha=C5=82 G=C3=B3rny wrote: >> Hello, >> >> After starting to deploy python-r1 on packages supporting multiple >> Python implementations, I believe it is time to start thinking about >> those packages which don't support that. Firstly, I would like to gain >> a general feedback/ideas on the possible solutions, without getting too >> deep into the technical details of it. >> >> As far as I can think, we have the following possibilities: >> >> >> 1) Assume that installing stuff for a single Python implementation is >> deprecated and let the packages rot with the old eclass. >> >> It is probably the simplest solution (i.e. not doing anything to >> address the issue) but truth be told, I doubt this will actually work. >> People will just keep using the old eclass which doesn't really do much >> good for those packages... >> >> And even if some people will actually start supporting multiple >> implementations... that may be even worse. Just look at dev-libs/boost >> to see what I mean. >> >> >> 2) Use a xor-type REQUIRED_USE for those packages. >> >> Put the whole set of PYTHON_TARGETS but add a REQUIRED_USE=3D'^^ ( ... )= ' >> for them, effectively requesting only a single implementation being >> enabled. >> >> I believe that this is quite a good solution, at least from >> the dependency point of view. We clearly express which Python >> implementations are supported by a particular package and which one was >> enabled. We can express cross-package dependencies cleanly. >> >> The problem lies in user-friendliness. Although with the current >> default (python2_7 only) it wouldn't cause any trouble, whenever user >> enables more than a single implementation, every single-implementation >> package will require package.use adjustment. This will become an even >> more widespread issue when we decide to re-enable Python 3. >> >> To be honest, I don't see any good way around that. >> >> >> 3) Use implicit implementation selection (like python.eclass). >> >> Well, as some say, this is a very good solution since it's well tested. >> Its limitations and brokenness are obvious. Just I doubt it is really >> worth the effort to write something that bad. >> >> The main problem here is that the chosen Python implementation is >> implicit. Binary packages don't express it. Cross-package dependencies >> don't express it. User changes the implementation, stuff breaks >> silently and you end up with some kind of python-updater (why a tool >> to fix breakage is called 'updater'?!). >> >> >> Do you have any more ideas? Opinions? >> > > Like you, I really can't come up with an ideal solution here. > > We really have 2 classes of packages here: > > 1. Packages that don't care what version of python you use, but > install files outside of site-packages. > > 2. Packages that build code (like libraries) against a specific > version of python/libpython. > > The implicit implementation selection works fine for #1, but not so well = for #2. I wonder if we could have a "special target" that could expand to the current eselected python version. That way, the package not supporting a multiple targets, could be treated the same as those who do. Something like: PYTHON_COMPAT=3D( python_current ), or something like that. --=20 Jesus Rivero (Neurogeek) Gentoo Developer