Bug 537246

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