I'm working on adding a python 3 stack to Fedora 13, parallel-installable with the main python 2 stack: https://fedoraproject.org/wiki/Features/Python3F13 There are two approaches I'm experimenting with to packaging modules for python 3: (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. See: https://fedoraproject.org/wiki/PackagingDrafts/Python3 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? http://stackoverflow.com/questions/1416005/python-virtualenv-python-3
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: http://bitbucket.org/ianb/virtualenv/issue/10/python-3-support 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 load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python3.1/site-packages/pkg_resources.py", line 2201, in load_entry_point return ep.load() 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> """.decode("base64").decode("zlib") 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: > http://pypi.python.org/pypi/virtualenv3 > http://bitbucket.org/brandon/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-1.7.1.2 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-1.7.1.2, 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: http://docs.python.org/3/library/venv.html#module-venv 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 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. commit 83fb3a6012a3bc5447d5a57a2893c65a49f03d8d Author: Matthias Runge <mrunge> Date: Thu Jan 15 11:14:18 2015 +0100 add python3 subpackage with 1.11.6-2