[Bug 217044] devel/py-setuptools: Upgrade to 34.1.1

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217044

--- Comment #4 from John W. O'Brien <john at 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.