Red Hat Bugzilla – Bug 537246
Last modified: 2015-05-06 12:14:06 EDT
I'm working on adding a python 3 stack to Fedora 13, parallel-installable with
the main python 2 stack:
There are two approaches I'm experimenting with to packaging modules for python
(a) create an separate specfile/srpm for the python 3 version
(b) extend an existing specfile so that it emits a python3- subpackage as
part of the build.
We have a preliminary, working python3-setuptools rpm, though not yet in CVS/Koji (see the tracker bug)
Any idea what upstream's plans are for python 2 vs python 3 support?
I don't know how they will be handling Python 3 users at the moment, so I opened up an issue with them to find out:
I'll if I can get it working with a 2to3 in the meantime.
A simple 2to3 invocation doesn't appear to be enough; I get a runtime failure
trying to extract the big base64-encoded script files in virtualenv.py; I'm
guessing these may also need 2to3 on them even after extraction:
Traceback (most recent call last):
File "/usr/bin/virtualenv3", line 8, in <module>
load_entry_point('virtualenv==1.3.3', 'console_scripts', 'virtualenv3')()
File "/usr/lib/python3.1/site-packages/pkg_resources.py", line 281, in
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3.1/site-packages/pkg_resources.py", line 2201, in
File "/usr/lib/python3.1/site-packages/pkg_resources.py", line 1920, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/usr/lib/python3.1/site-packages/virtualenv.py", line 1093, in <module>
AttributeError: 'str' object has no attribute 'decode'
Created attachment 369337 [details]
separate specfile that builds but shows runtime errors
As noted on: http://bitbucket.org/ianb/virtualenv/issue/10/python-3-support#comment-110814
> Brandon Rhodes forked and seems to have a working virtualenv3:
It's not clear to me how "official" the fork is.
Packaging this as, say, python3-virtualenv.spec would be approach (a) in comment #0 above.
I think (a) is going to be the best option at this point.
It seems like work on the fork has stopped :-(
Good news is that virtualenv 1.6 has official Python 3 support :-)
Created attachment 491905 [details]
draft spec update
I did a lot of copy/paste from python-nose to have python-virtualenv 1.6 with a python3 subpackage. No runtime testing so far.
Actually the spec above works for me on Fedora 14.
Created attachment 576707 [details]
python3 support for python-virtualenv-18.104.22.168
proposed patch adds a Python3 subpackage for python-virtualenv. Works for me on F16.
Felix, I think the patch should be revised (only slightly) to move the exectuable from "virtualenv" to "python3-virtualenv" instead of "virtualenv3" as you have done.
See the discussion of "python3-coverage" here http://fedoraproject.org/wiki/Packaging:Python
Other than that, it looks great. Is there anything else standing in the way of applying this and creating an update?
(In reply to comment #11)
> Other than that, it looks great. Is there anything else standing in the way
> of applying this and creating an update?
I don't have commit access to virtualenv and Steve did not express any interest in this so far.
I'll update my patch and hopefully we can set this one as fixed then :-)
Created attachment 597734 [details]
python3 support for python-virtualenv-22.214.171.124, using python3-virtualenv for the executable
I updated the patch so that the executable is named python3-virtualenv. I didn't test it on rawhide but the F16 version works well and I believe rawhide will just be fine as well.
One thing I noticed is that the python3 package includes '__pycache__' directory and I'm not sure if we should package that.
I now applied for commit access to python-virtualenv, so hopefully I'll be able to resolve the bug myself soon. Would be grateful to get this bug of my plate soon.
You should package it, I think; it gets re-created during runtime. That's where the *.pyc and *.pyo files get stored for python3.
Any updates on this?
I'd note that in python 3.3, virtualenv have been moved into the core:
In my opinion, there is no longer a need for a python3-virtualenv. With due respect for those who worked on it, I propose that the owner or reporter close this bug as wontfix.
I've just tried `virtualenv` from the `python-virtualenv` package and it is able to successfully create and activate Python 3 virtualenvs (provided that `python3` package is installed, of course):
$ virtualenv --system-site-packages -p /usr/bin/python3 py3k.env
$ source py3k.env/bin/activate
Python 3.3.0 (default, Sep 29 2012, 22:33:28)
So it would appear that the problem has solved itself with time :-) Thus I second the notion that this bug can be closed.
But why do I see so many distros have parallel installable package of virtualenv...
This was fixed a while back.
Author: Matthias Runge <email@example.com>
Date: Thu Jan 15 11:14:18 2015 +0100
add python3 subpackage