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 4F5C11381F3 for ; Sat, 3 Nov 2012 15:55:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0CD8FE04AB; Sat, 3 Nov 2012 15:55:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5755FE04AB for ; Sat, 3 Nov 2012 15:55:41 +0000 (UTC) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) (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 7E70F33D7E6 for ; Sat, 3 Nov 2012 15:55:40 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id m6so1892693eab.40 for ; Sat, 03 Nov 2012 08:55:37 -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.14.172.137 with SMTP id t9mr18406427eel.2.1351958137718; Sat, 03 Nov 2012 08:55:37 -0700 (PDT) Received: by 10.223.75.137 with HTTP; Sat, 3 Nov 2012 08:55:37 -0700 (PDT) In-Reply-To: <20121103114731.GA3150@localhost> References: <1351770893-1217-1-git-send-email-mgorny@gentoo.org> <20121101222719.2717ff05@pomiocik.lan> <20121101224242.GE3299@localhost> <20121102100305.4acfc927@pomiocik.lan> <20121103033538.GI3299@localhost> <20121103083346.1d21d1a5@pomiocik.lan> <20121103114731.GA3150@localhost> Date: Sat, 3 Nov 2012 11:55:37 -0400 Message-ID: Subject: Re: [gentoo-python] Re: [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well. From: Mike Gilbert To: Brian Harring Cc: "Micha?? G??rny" , gentoo-python@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 8ded31d6-7a2e-4ebe-a55f-5e1e3075bbf1 X-Archives-Hash: c1f120eea1253bd6ac683fdf47b0fcff On Sat, Nov 3, 2012 at 7:47 AM, Brian Harring wrote: Some quick notes on these last points. Don't get too hung up on this; my general opinion of the solution follows at the end. > Your implementation mandates the following: > > *) scripts be changed from sphinx-build-2.7 to sphinx-build-python2.7. > The was a design decision to simplify the implementation in conjunction with the new eclass and avoids having to map a plain number (2.7) to an actual interpreter name (python2.7). I still like this idea, but it really isn't safe to do this in the old eclass. > *) mandates symlinks of python-EPYTHON were it to be attempted to be > used for python-wrapper. > python-exec was not originally intended to replace python-wrapper so there is no code in place to handle this more gracefully. > *) removes the ability to do $PYTHON_INTERP /usr/bin/script > Nobody dreamed up this scenario when python-exec was proposed. It seems pretty obvious now, but I didn't think about it until our email exchange about your original proposal. > These are the sort of things that would've been identified with tests. > I don't see how tests themselves would have identified these issues, since we are talking about testing use cases that had not yet been identified. Or that had deliberately been changed, in the case of the script rename. I guess you may be implying that thinking of test cases would have triggered some deeper thought and revealed flaws that were not immediately apparent. That's probably true. > Python herd, assuming you've not ignored the thread due to the noise, > your views would be useful. Just so everyone is on the same page here: python-exec was invented as an answer to the problem of how to implement script wrappers in the new eclass. The new eclass(es) were invented because nobody wanted to make significant modifications to the old one, given its complexity and code style. I don't think we were aiming for a perfect solution with python-r1 and python-exec, rather one that was simple so people could understand, and worked in the cases we considered at the time. Your main goal with python-shebang seems to be a fix to the "python2.7 /usr/bin/sphinx-build" thing, which is fine. But it lead you to a different place. That said, I like this python-shebang solution, and your replies to mgorny's questions have provided very useful insight. However, I have a few issues: 1. I still don't really understand the guts of python-shebang. It's a significant chunk of C that is doing things I am not yet familiar with. I'm sure I can figure it out if I take some time, but right now I have a "fear of the unknown" thing happening in my head. I don't want us to end up with only you understanding how to modify that code. 2. Somebody needs to write the python.eclass code if we really want to go there. I think we would need to modify python_merge_intermediate_installation_images, and replace python_generate_wrapper_scripts. If anyone wants to take a crack at it, great. 3. We need to reconcile the script naming convention so we can use this with the new eclass as well. I just don't see us implementing PYTHON_TARGETS in python.eclass. I have considered it, but I just don't have the motivation to do it. I still think we are going to proceed with the python-r1 effort. What do you think about extending python-shebang to understand the script-$EPYTHON naming convention in addition to the script-$PYTHON_ABI convention? I only ask because I dislike the $PYTHON_ABI values and would rather not see that re-implemented in python-r1. I think script-$EPYTHON gives a clearer indication as to its intended purpose anyway.