Bug 1024799
Summary: | python-fedora: Support Python 3 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> |
Component: | python-fedora | Assignee: | Fedora Infrastructure SIG <infra-sig> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | a.badger, jonstanley, lmacken, maziangamy, rbean, ricky |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-05-04 16:38:30 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1024800, 1024802 | ||
Bug Blocks: | 1024795 |
Description
Miro Hrončok
2013-10-30 13:05:31 UTC
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. https://rhn.redhat.com/network/software/channels/details.pxt?cid=18330 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: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 python3-fedora is out! https://admin.fedoraproject.org/updates/FEDORA-2015-7250/python-fedora-0.4.0-1.fc22 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. |