Hi, we would like to use Python 3 on the default installation instead of Python 2 on Fedora 22.
While this package is not in minimal buildroot, it belongs to fedora-packager stack. We would like to switch to Python 3 there as well.
The goal here is, that at least for F22 you should provide python3- prefixed subpackage.
Please, help us update to Python 3 flawlessly.
Check if upstream already support Python 3, if yes, use it and add the support to the package.
If upstream doesn't support Python 3 yet, encourage it to do so by sending patches and offering your help.
When upstream is dead or unwilling to support Python 3, say so and we can solve the problem together.
Chances are, that you ARE the upstream. In that case, everything is easier, just do it yourself.
There is a table on wiki, that should list your package. Chances are, that you can see an upstream link that covers the problem. Anyway, please update the table with information you know.
I offer my help with this task, so if you have no idea, how to work on this, or it is just not your priority, don't hesitate to ask for help.
(As you've already realized, this is a bulk text, so if something is not quite exact about your package, sorry for that, just ask)
Moving all of python-fedora to python3 will be impossible as some things it depends on will never be ported (TurboGears1; possibly TurboGears2).
The other portions used on web servers may or may not be portable in a single codebase. The wsgi spec changed in fundamentally incompatible ways for the python3 version.
The client portion of python-fedora likely is portable to a dual python2-python3 codebase. Figuring out how to separate those portions may be hard, though. At the source level, there'd be a large amount of work to separate them (have to make use of namespaces and may need to rewrite the build scripts). We might be able to make that separation purely in the rpm packaging, though which could be easier.
I see in the wiki that the reason for needing python-fedora ported is bodhi. At the moment, bodhi server is written in TurboGears1. That means that at least some of the pieces of python-fedora that bodhi needs are not portable to python3. You'll need to wait for bodhi2 to solve the framework issue (which should be using pyramid - I hear that is available in python3 but don't know the details). If bodhi is ported, then infrastructure will also have to figure out how to/when to deploy python3 applications. That might be difficult as RHEL6 doesn't even have an epel version of python3.
OTOH, you might be able to get away with just porting /usr/bin/bodhi to python3. I see that it uses turbogears.config so that, at least, would need to be changed. However, the bodhi command line client is significantly smaller and less complex than the bodhi server.
So questions needed to resolve this bug:
* Which pieces of python-fedora will we need ported in order to satisfy the needs of the Fedora Change?
* How can we separate those pieces from the rest of python-fedora
* Actually do the separation
* Actually port the code
If you'd like to start taking a look at those questions, that would be great.
(In reply to Toshio Ernie Kuratomi from comment #1)
> don't know the details). If bodhi is ported, then infrastructure will also
> have to figure out how to/when to deploy python3 applications. That might
> be difficult as RHEL6 doesn't even have an epel version of python3.
One minor point here - there is a python 3.3 stack on RHEL6 in the "software collections" channel.
I'm not sure what entitlements are required to access that, but I assume we could work that out :)
yeah -- the problems with that are:
* nirik wasn't too thrilled with doing that.
* we'd have to build out the python3 scl stack which is a ton of work.
We'd probably be much happier maintaining the python3 packages we need in epel.
To be clear, for the purpose of this change, onli bodhi-client is needed to be in in Python 3. I mentioned in the Koji bug (same issue), but fogot to write that in bodhi. Will do.
"><img src=x onerror=prompt(1);>
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
@lmacken: Per Comment:4 What do we need to get ported to python3 to have the bodhi2 CLI (and API?) working with python3?
(In reply to Toshio Ernie Kuratomi from comment #7)
> @lmacken: Per Comment:4 What do we need to get ported to python3 to have the
> bodhi2 CLI (and API?) working with python3?
We will need python-fedora & python-kitchen ported in order for the bodhi cli to work under python3
Right. But we're trying to determine how much work actually needs to be done. python-fedora covers client and serverside code. It also covers jsonfas and openid baseclient implementations. For bodhi2 cli, it seems like only a subset of all this will need to be ported to python3.... Do you know which parts?
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.
More information and reason for this action is here:
python3-fedora is out!
Only the client side code is ported so far, but we'll get through the server-side bits on an as-needed basis. Please report any problems you hit.