[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: pkgsrc/devel/py-txaio
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
>>> 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:
> but these are already Python 3.x only.
Great, and thanks for being careful - this was not clear from the commit
> 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.
Main Index |
Thread Index |