Make Python 3.x compatible

[Conan-Kudo]

It appears that Smart is a Python 2-only application. As distributions aim to make Python 3 the default (such as Fedora) and only included Python release on install images, it would be excellent to have Smart ported to Python 3.

[afb]

Already made such a port, when Ubuntu threatened to replace python with python3 earlier (2012):
https://github.com/smartpm/smart/tree/py3k

However, Smart is not supported on Fedora anyway so it probably doesn't make any difference.
Python will still be available, even if not the default:

The Python 2 stack will stay in Fedora, it will just not be the default one. Depending on the modifications done to Python packaging guidelines, this probably means that Python 2 packages will stay the way they are and default tools will drag in python3- dependencies. Upstream recommends that /usr/bin/python point to Python 2 runtime for the time being, so if we go with that, there shouldn't be any serious compatibility impact:

• Users will still be able to install Python 2 packages
• Both Python 2 and 3 stacks will still live in parallel

But at the moment there is no way to combine the python2 and python3 variants into one tree, and no apparent advantages from changing to python3 ?

[Conan-Kudo]

There are ways to have a single tree that supports both variants of Python. Fedora's dnf did it. Depending on the extent of the modifications required, it may be possible simply by using the built-in future library or you may also need python-modernize.

I filed this bug because I wanted to bring smart back into Fedora (provided that RPM and Yum repos are still supported). The only reason it was dropped is because 1.3.1 failed to build in Fedora 18 and Fedora 19, which made it automatically get retired in Fedora 20.

[afb]

There were other reasons, but Smart was (and probably is) still compatible with Debian and CentOS even if it fell out of fashion with Ubuntu and Fedora... The main issue was that the current database design cannot cope with the amount of packages, or with the start and stop timing requirements of PackageKit.

There was also some features missing, such as the yum comps or the sqlite repodata. And a lot of the recent features like libsolv (hawkey) are going to be hard to support and still maintain deb compatibility. So you would have to post a lot more details on your ideas for smart, on how to get "there" - from "here".

Note that the current codebase supports Python 2.3 through 2.7, for legacy compatibility reasons...

[Conan-Kudo]

So the reason why I want to bring smart back into Fedora is because I'm considering using it for a Fedora based distribution spin/remix. That being said, I don't expect you to integrate hawkey into smart, since that fundamentally changes how it would do dependency resolution.

I don't quite understand why smart would have a problem with the number of packages, since Debian and Fedora are relatively close in the number of packages in the distribution (Debian has a few thousand more, in fact). As for the timing requirements of PackageKit, I don't currently intend to really use that with smart, but it would be nice if that was resolvable. That said, doesn't PackageKit already have support for smart as a backend?

Also, I have no idea if smart supports DeltaRPMs or not. It's not required, but that would be pretty good to have. Yum comps and SQLite repodata support is kind of critical, though. What would it take for you to get that supported?

[afb]

I don't see how porting to python3 would help with any of this, but we probably want to continue the other discussion elsewhere (not in this python3 issue)...

The current problem with packages is that users are reporting problems with too many packages and especially loops, and the problem with PackageKit is that the startup/shutdown time is "too long".
There is no way to support delta packages (bsdiff/bspatch) without redoing alll the fetch phases, and adding yum comps will require model changes (and not all rpm distros need/use them). Support for sqlite repodata was added here, but it didn't really add anything... It is also obsolete now with the solv, so might as well continue to use the xml ? So I don't think that either of DeltaRPMs or SQLite are blockers.

You can give the "py3k" branch a try, but it seems that to fix the current issues with smart that it would be better to port to a different (compiled) language altogether...

[fan-xin]

Already made such a port, when Ubuntu threatened to replace python with python3 earlier (2012):
https://github.com/smartpm/smart/tree/py3k

Is this means the smart has finished porting to python 3 ?

We also want to port smart to python 3 because we want to continue to use it.

About this issue, any progress ?