Re: CVS commit: pkgsrc/devel/py-txaio

[Greg Troxel <gdt%lexort.com@localhost>]

Adam <adam%netbsd.org@localhost> writes:

>>> Module Name:	pkgsrc
>>> Committed By:	adam
>>> Date:		Thu Jan 23 14:20:35 UTC 2020
>>> 
>>> Modified Files:
>>> 	pkgsrc/devel/py-txaio: Makefile PLIST distinfo
>>> 
>>> Log Message:
>>> py-txaio: updated to 20.1.1
>>> 
>>> 20.1.1:
>>> Drop support for Python 2.x.
>> 
>> Can you explain whether there is anything in pkgsrc that is 2.x only
>> that depeends on this?   I can't tell from your commit messsage whether
>> you are sure there aren't, in which case this is ok.  Or whether this is
>> breaking something, in which case it's not ok according to the plan of
>> how to cope with the 2.7 situation.
>
> I checked that before committing (I always do). py-txaio is required by:
> devel/py-buildbot
> www/py-autobahn
> www/py-daphne
> but these are already Python 3.x only.

Great, and thanks for being careful - this was not clear from the commit
message.

> By the way, there are more and more packages that drop 2.x support. It
> has become extremely difficult to maintain 2.x compatibility within
> PkgSrc. (For exmaple, I am still holding an import of newer Numpy
> along with the old one, because of the tedious work that has to be
> done). I guess, in the end, it is a question of having up to date
> package versus keeping the stale ones for the sake of the dead Python.
>
> That's my observation. :)

I agree this is getting harder and harder.

But it's not dead python we are accomodating -- it's the 2.7-only
programs that users use.  It seems that even now there are in-use
programs that have not yet migrated to 3.   Examples are gnuradio and
bup, at least, and I don't think it's just those two.

I do not mean to say that we should never decide to abandon something
that is 2.7 only and doesn't update to 3.   I really mean that this
should happen only with explicit proposal and discussion, as if it were
a removal.   The entire process (outside pkgsrc) of the python2->3
transition in my view has not gone well.

Can you explain what you mean about numpy?  Are you saying that
reimporting the last 2.7 version and pointing the 2.7-only things at it
is a lot of work?  Is that because of complicated dependency chains where
the intervening packages are ok with 2.7 or 3?   Because of namespacing?

I see 35 packages from find-depends on py-numpy, but it seems
finddepends only finds usage via bl3, and not the straight DEPENDS+=
common within python.

Do we have any easy way to generate a report for a given package that
describes the set of 2.7-only packages that depend on it?  It seems that
would be helpful in assessing how to steer.