Any fixes in work for py-setuptools for python 3.3+ ?

[John Marino]

On 12/24/2013 17:54, William Grzybowski wrote:
> On Tue, Dec 24, 2013 at 4:43 PM, John Marino <freebsd.contact at marino.st> wrote:
>> The impact is that they will disappear from dports, because we don't
>> feature ports that can't have binary packages.  I'm sure there was a
>> good reason for the change that caused these ports not to build in
>> poudriere, but that change did cause damage.  I'm not in a position to
>> say if the tradeoff is worth it because I don't understand what was
>> gained (only what was lost).
> 
> If you want to provide packages with the non-default python version
> you can use DEFAULT_VERSIONS= python3.3 for your poudriere make.conf.

Unfortunately, that's not a practical solution.  It's always difficult
to have a different default than FreeBSD, although we did this for Ruby
until FreeBSD caught up and we still do it for PostgreSQL (DragonFly
defaults to 9.2).  There will be fallout to change the default, and I
suspect the reverse problem will be worse (ports needing python < 3.3
will break the same way).

> 
> The issue here is that the dependency list is built with poudriere
> using PKGORIGIN, however py-setuptools can have several distinct
> PKGNAME, depending on your chosen python version.
> We are not going to provide a new port for every python version of a package.

Given how many ports depend on py-setuptools, maybe that policy should
be reconsidered for this particular port.  The current arrangement is
anti-binary package and I understand that FreeBSD ports is trying to
transition from the standard of building ports from source to installing
binary packages.  The regression is unfortunate.  Hopefully someone will
try to figure out a better solution.  For now, I have no choice but to
remove all these python 3.3 + py-setuptools since they are now
unbuildable in poudriere.

John