From owner-freebsd-python@freebsd.org Mon Feb 13 03:01:07 2017 Return-Path: Delivered-To: freebsd-python@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7388CDC5FB for ; Mon, 13 Feb 2017 03:01:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABC0B21 for ; Mon, 13 Feb 2017 03:01:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8A1FBCDC5FA; Mon, 13 Feb 2017 03:01:07 +0000 (UTC) Delivered-To: python@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89BFECDC5F9 for ; Mon, 13 Feb 2017 03:01:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 70E5DB1D for ; Mon, 13 Feb 2017 03:01:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v1D316O2053931 for ; Mon, 13 Feb 2017 03:01:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 217044] devel/py-setuptools: Upgrade to 34.1.1 Date: Mon, 13 Feb 2017 03:01:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: john@saltant.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: python@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? exp-run? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 03:01:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217044 --- Comment #4 from John W. O'Brien --- (In reply to Antoine Brodin from comment #2) Upon further reflection... A solution that uses ensurepip *without* a way to upgrade pip and setuptools (P&S) more frequently than python itself would be a step backwards, because= we could not straight forwardly patch either one of them. The ports machinery wants patching to happen between extraction and configuration, while --with-ensurepip=3Dinstall wouldn't make the guts of P&S available for patc= hing until the midst of staging. Furthermore, the unpatched, bundled version of S would still suffer from the lack of globby grafts that led to bug 216953, because globbing reportedly broke after v28.4.0 [0] which affects the bundl= ed v28.8.0. Therefore, we *must* retain the ability to upgrade P&S between pyt= hon releases *or* to patch it locally (or both). So, what options are available for doing that? Let's start with my suggesti= on from comment #3: drop in new wheels during production of a lang/pythonXY package that are fetched as distfiles or patches and inserted into WRKSRC somewhere between post-fetch and pre-stage. There are two problems with thi= s. First, it still doesn't solve the local patching limitation because P&S wou= ld still appear as wheels until after the stage phase. Second, in order to upg= rade setuptools to v34.0.1 or later to thoroughly satisfy to goals of bug 216953= , or for some other reason that may present itself before upstream python decides how to bundle v34.0.1 or later for ensurepip and releases a new version, we would have to make that decision locally and implement it. Another disadvantage of tying P&S to lang/pythonXY is that any any patch or upgrade to P or S will induce a PORTREVISION bump to lang/pythonXY and associated rebuild of all ports that depend on it, which is a good deal more than the ports that depend on P or S. This pushes me back toward wanting to retain P&S as independent ports, and to think about other strategies for dealing with tricky dependencies. Taking a page from the ensurepip book, a third family of options could be b= ased on implementing a wheel-oriented install for a small number of ports (proba= bly all of those mentioned in comment #1) but treating devel/py-pip as the root= of the dependency tree and depending upon it as a BUILD_DEPENDS for as much of= the wheel installation implementation as possible (instead of DIY in Mk/Uses/python.mk). The key integration points would be: 1) Retain the ability to patch one of those ports locally, possibly by movi= ng the patching to a post-stage target, or moving the pip-managed wheel installation to a pre-patch target with a WRKSRC destination and implementi= ng the stage target as a dumb bunch of cp commands. 2) To the extent that wheels are involved, fetch and verify them with the p= orts machinery and then feed to pip to preserve the integrity and authenticity of the ports. 3) Generate PYC/PYO files. 4) Draft a packing list (a la autoplist) from pip's work and merge the byte= code files into it. I think that's all I've got for now, and welcome reactions. [0] https://github.com/pypa/setuptools/issues/935#issue-202591204 --=20 You are receiving this mail because: You are the assignee for the bug.=