Adam <adam%netbsd.org@localhost> writes:
>> textproc/py-cjson - only for Python 2.7; no dependencies
>>
>> www/py-cherrypy17 - Python 2.7 version of www/py-cherrypy
>
> Since Python 2.7 has become obsolete, it is more and more difficult to
> maintain Python packages. Packages are dropping 2.7 support
> quickly. Many Python updates in PkgSrc are blocked by this fact. IMHO
> we should move toward dropping Python 2.7 as well. Providing older
> version just for keeping Python 2.7 compatibility creates a dependency
> nightmare.
>
> I say, we should get rid of some old and unmaintained Python packages to clean the mess.
In the case of py-cherrypy17, I don't even know what it does, but in my
view the real work is setting up the old version, and I don't see what
reduction in work deleting it gets us, as opposed to just leaving it and
not really caring if it builds
CherryPy is a web application server, similar to Flask or Django. While I don't use this pkg specifically, and I think most folks will be installing this via pip/PyPI anyway, looking at the setup files it doesn't look like there would be a build issue. There may be some optional dependencies (
https://github.com/cherrypy/cherrypy/blob/maint/17.x/setup.py) that are breaking, but this should be made especially optional in an
options.mk and left up to the user who wants the optionals to resolve; this would ensure a default pbulk continues to succeed.
So I'd like us to be on the slow side to remove the 27 version of split
old/new packages. There, I think the argument to remove should be "I
don't believe that anybody is actually using this for any reason."
For packages that would normally be updated to a 3.x version from a
2.7/3.x version, there the question is whether a 2.7 version needs to be
added or not, and that's where I see the harder questions.
I concur, the default policy should be "if it ain't broke..." The harder questions, as you say, revolve around the amounts and tolerance of brokenness .