https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217044
--- Comment #4 from John W. O'Brien <j...@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=install wouldn't make the guts of P&S available for patching 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 bundled v28.8.0. Therefore, we *must* retain the ability to upgrade P&S between python releases *or* to patch it locally (or both). So, what options are available for doing that? Let's start with my suggestion 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 this. First, it still doesn't solve the local patching limitation because P&S would still appear as wheels until after the stage phase. Second, in order to upgrade 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 based on implementing a wheel-oriented install for a small number of ports (probably 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 moving the patching to a post-stage target, or moving the pip-managed wheel installation to a pre-patch target with a WRKSRC destination and implementing the stage target as a dumb bunch of cp commands. 2) To the extent that wheels are involved, fetch and verify them with the ports 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 bytecode 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
