Python2 support using nine

[ondrejj]

Python2 counter is ticking, but kajiki still needs python-nine to run on python3. Looks like there is no release of nine after year 2016. Do you think, that kajiki still needs python-nine?

Currently build of kajiki in Fedora 32 (development) is broken due to problems with python-nine. I suggest to release a new version of kajiki, which will not rely on python-nine.

[amol-]

Personally I prefer to have libraries not rely on compatibility layers like six or nine. so I'd be more than willing to change Kajiki to not require nine. I had a pull request around a few years ago, but I don't even recall where it's available.

@nandoflorestan what's your thought about this? Is there a reason why we should keep nine around in Kajiki instead of using a _compat for the few places where adapters are needed?

[nandoflorestan]

The reason there's no recent release of nine is that Python 2 compatibility is an old and solved problem. Or do you want me to update the copyright and make a new pypi release to make this silly argument go away? (This is an honest question, by the way -- I might do exactly that.) There are no pull requests and no unsolved issues in the nine project. It is a super simple Python module.

Further, anyone who avoids depending on any library and brings the code into their project instead is wrong in principle (as the Django project is an example of). This hurts code reuse, is bad for security and hurts proper software architecture. One needs a very specific reason in order not to reuse a library.

Honestly, please just solve the bug in the proper abstraction layer. I am not aware of "problems with python-nine in Fedora" and if there are any problems, well then solve them in Fedora, because the nine package is as simple to get right in packaging as it can be -- nothing could be easier.

In fact, it will be easier to solve any Fedora packaging issue there might be, than changing a couple dozen lines in Kajiki to lose the nine dependency.

Finally, Python 2 reaches end of life when the year number increments. In 2020 Python 2 is officially dead. It is November 2019. Why is this even being brought to our attention? Why do anything at all? Isn't it a developer's duty to be porting any Python 2 applications to Python 3? My other libraries haven't supported Python 2 for YEARS now.

Even I do not use nine anymore.

If you are going to spend time changing Kajiki, then you should change it now to remove ALL support for Python 2 which is a dead project. But this is only my opinion.

Alessandro Molina, thank you for listening to my opinion. As always, you are the official maintainer of the Kajiki project and what you decide goes. And I continue to admire your work in the Python community, including old projects that you wrote and I wasn't aware of. Do what you think is best!

[nandoflorestan]

After writing the above I re-read your messages and I realized you might mean you also don't think Python 2 support is needed, so maybe we are all on the same page.

@ondrejj you only wrote a couple of lines but if you are using the Fedora package manager to install nine on a development machine, well nobody recommends that. You should create a virtualenv and use pip to install nine and all the other Python dependencies on the virtualenv. And this is super easy to do.

[ondrejj]

Currently in Fedora nine lost it's packager and was retired. But I asked to be a maintainer of nine and plannint to add it again.

And about your note to pip. I am a Fedora packager, packaging TurboGears2 in Fedora, which required kajiki to install. I don't use kajiki in my projects, but because it's required by TurboGears2, I have to use it. An Fedora package can't use pip to install, must use packaged files.

May be I filled this bug too early, python2 is still supported, but I think making a new version of kajiki can take a time. I also needed to know, what is your opinion about removal of nine requires before I ask to adopt nine package in Fedora.

[nandoflorestan]

@ondrejj

Thank you for the clarifications. As a Fedora package maintainer, if you need anything from me as author of nine, all you need to do is ask, and I will be glad to help.

My opinion is that using nine is better than using six (because it looks more like Python 3) and using any of them is better than rolling your own. It's a matter of principle in packaging. Avoiding dependencies is silly.

But Alessandro Molina will probably stick to his original opinion for pragmatic reasons, he's the boss and he was just being nice by including me. I have no problem with that.

[amol-]

I don't have a strong opinion. My proposal was based on the fact that Kajiki uses very little of nine features. And most of them it could probably live without by reducing support for Python2 ( worse support for repr and unicode etc... ).
So I was wondering if we could replace a dependency with a module of 5-10 lines of code.

But my understanding was based on the fact that nine was causing problems to Fedora packaging. If all we are talking about is "packaging" nine itself. I think it's something that poses no complexity given nine hasn't changed in years.

Also I wonder if it's correct that the TurboGears2 package depends on Kajiki.
It's not TurboGears itself that depends on it, it's the application that you quickstarted that might depend on Kajiki if you didn't chose any other template engine. So I question if Kajiki should be a dependency of TG at all or if it should be delegated to the moment the user does pip install -e myapplication like it is in the PyPa world.

[ondrejj]

python-nine has been adopted by me in Fedora, builds fine, so Fedora's kajiki problem are solved. I will contact @nandoflorestan , if there will be any problem in future.
Thanks for help.
RHEL 7 and CentOS 7 will support python2 until it's EOF, so may be using python-nine will still be useful some years. But don't think, that all python packages will be supported, so may be it's still better to support 2 different branches, one for python2 with only basic maintenance and to use main development in python3 branch. Consider, if you close this bug or leave it for future.

[amol-]

Closing for now, will reconsider as Python2 gets deprecated