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 506481381F3 for ; Sat, 3 Nov 2012 21:31:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC6E6E0486; Sat, 3 Nov 2012 21:31:16 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 34189E0486 for ; Sat, 3 Nov 2012 21:31:15 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id wz12so3011781pbc.40 for ; Sat, 03 Nov 2012 14:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=KqMTWq7v4BaIlWW0UNHcUaDjbH9HB6D7KBdZcjkVL8Q=; b=hlRYY9ZLxZyEZ8PzA0sTOJAMscNLnsqiJX6doanWTxMQPEoW1mP3rNhfkxDOXD406v UqRfjuhGA8qWtqcMC+sPS7xYULsvsrvCttODANhpFoS2pnl9hXaNp6nsPb8fL1whsMvn a1B/rdqvh+jcdsmF6+RolylX3aWxjMPayWcjqjpvlflBlMHYftoeWvcMUh8Rxhvozt1T lZYRzZ/fpJAFL8MiCfLDuMMPZ/rMYJZuX/e5x5HG2dE82UF7aKmlyqWqxD/ydQHOB/jX B+0Cq+WQc0ggR8TRJWIvcIopDJLqJbkLrUhZGXH/fmWOl2tE4frE/x4agxeyYBKIjQey bpbA== Received: by 10.68.143.162 with SMTP id sf2mr17747324pbb.137.1351978275326; Sat, 03 Nov 2012 14:31:15 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id ve6sm7889522pbc.58.2012.11.03.14.31.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 14:31:14 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sat, 03 Nov 2012 14:31:12 -0700 Date: Sat, 3 Nov 2012 14:31:12 -0700 From: Brian Harring To: Mike Gilbert Cc: Micha?? G??rny , gentoo-python@lists.gentoo.org Subject: Re: [gentoo-python] Re: [PATCH eselect-python 1/2] Store per-version interpreter preference in a file as well. Message-ID: <20121103213112.GB3150@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> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 02b7004c-dc68-4845-b8eb-ced8c0f96d33 X-Archives-Hash: 4bbfddd472fba24a56dd9157121459c0 On Sat, Nov 03, 2012 at 11:55:37AM -0400, Mike Gilbert wrote: > 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. Renaming sphinx-build-2.7-pypy-1.8 to sphinx-build-pypy-c1.8 (or just 1.8) personally I think is sane; the original naming was off, and I doubt any code actually hardcodes it. I don't see the point in shoving -pythonx.y when -x.y suffices however- the parsing scenario there is easy to handle for any wrapper, and is understood for folks these days. Additionally, because the advocated route of forcing a specific interp for a target has thus been invoking the interpretter specific script (sphinx-build-2.7 for example), changing the name for python means breakage may occur. How much breakage, I've no clue; just pointing out that it is possible. > > *) 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. It was proposed, which is why I responded to it. Same angle, the cons of python-exec compared to python-shebang were asked, so this got brought up. python-wrapper is literally just a a simple re-exec around python-shebang now. > > 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. Close; my main goal was replacing that fucking python wrapper, and fixing `python2.7 /usr/bin/sphinx-build` while speeding everything up. I've got a couple of core requirements, but they pretty much sum up to "the existing wrapper needs to die"- everything else (de-duplication reducing the number of files on disk) is icing on the cake. > 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. That can be rectified via more comments. Honestly it's pretty simple- just trace the main(); everything else is just helpers to it. The flow there should be pretty clear as to what it's doing. The actual invocation scenarios, and details of how it covers each of those, can be addressed via a README (or similar) easily enough. There's a few subtlies there as to how it manages to do the correct thing, which I should document. > 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. Already have local patches to that effect; as indicated in my original email, I'm busy with some other things atm, but I'll loop back to it in the next week or two. If someone else wants to finish it, they're free to. Else I will. > 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. Off the top of the head, it's easy enough to support both w/ python-shebang code; it's just an extra case or two for the core parsing. I *do* intend to keep the current parsing in place though- as I said, I want this idiocy fixed in python.eclass now (and as demonstrated, I'll do the work myself if necessary). Removing that blob of code out of python.eclass won't fix the eclass, but it'll at least bring down the line count a bit so there's less to have to work with. Plus if a replacement actual ground, this component doesn't need changing (if it ain't broke, don't fix it). ~harring