Date: Mon, 13 Feb 2017 03:01:07 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 217044] devel/py-setuptools: Upgrade to 34.1.1 Message-ID: <bug-217044-21822-H1od00msu2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217044-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-217044-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217044 --- Comment #4 from John W. O'Brien <john@saltant.com> --- (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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217044-21822-H1od00msu2>