Skip to content

Creation of a new virtuelenv with Python 3.3 fails #329

michaelklishin opened this Issue Sep 6, 2012 · 31 comments

6 participants


When trying to provision 3.3 RC1 [upd.: and later RC2] for, I am hitting the following (Chef output):

I am not familiar with the Python ecosystem enough to understand if this qualifies as a virtualenv problem but decided to file this issue. If there are workarounds, I think we can tweak things just for 3.3.

jezdez commented Sep 6, 2012

Is that the latest version of virtualenv/pip?

pnasrat commented Sep 6, 2012

This looks similar to the issues I addressed on OS X for 3.3, which should be fixed in latest virtualenv/pip.

You probably need the virtualenv on the base image to be 1.8.1 - if you need a PPA or whatever for that, then I'm not sure where to look but it should be easy to package.

ISTR It's possible to create a travis vagrant instance from your OSS repos - can you point me at a scriptable reproducer and I can poke more.

pnasrat commented Sep 6, 2012

I'm going to hop on IRC to see if we can get a quicker turnaround

pnasrat commented Sep 6, 2012

Full logs:

Looks like possibly something odd in the new ubuntu packaging with the minimal package

PKG source

  Traceback (most recent call last):
    File "", line 220, in <module>
      scripts = scripts,
    File "/usr/lib/python3.3/distutils/", line 148, in setup
    File "/usr/lib/python3.3/distutils/", line 917, in run_commands
    File "/usr/lib/python3.3/distutils/", line 935, in run_command
    File "/usr/lib/python3.3/distutils/", line 107, in ensure_finalized
    File "build/src/setuptools/command/", line 29, in finalize_options
    File "/usr/lib/python3.3/distutils/command/", line 334, in finalize_options
      (prefix, exec_prefix) = get_config_vars('prefix', 'exec_prefix')
    File "/home/travis/virtualenv/python3.3/lib/python3.3/distutils/", line 92, in sysconfig_get_config_vars
      real_vars = old_get_config_vars(*args)
    File "/usr/lib/python3.3/distutils/", line 505, in get_config_vars
    File "/usr/lib/python3.3/distutils/", line 449, in _init_posix
      from _sysconfigdata import build_time_vars
    File "/usr/lib/python3.3/", line 6, in <module>
      from _sysconfigdata_m import *
  ImportError: No module named '_sysconfigdata_m'

The package we use wasn't very heavily tested but the maintainer is very kind and I think we can ask him to rebuild it if we identify what is missing/wrong.

hukka commented Sep 9, 2012

You are hitting virtualenv bug #301 in combination of either (3.3rc1) or (rc2).

carljm commented Sep 9, 2012

Thanks @tpievila for the additional pointers. #301 is an error-reporting/debugging improvement, not something that will cause a failure itself; so if that's correct this is not something we can fix in virtualenv. Fortunately it looks like is fixed in 3.3rc2, and is not hard to work around if needed. Closing for now, unless more information is provided indicating this is a virtualenv bug.

@carljm carljm closed this Sep 9, 2012

@carljm does it mean that using RC2 will solve the issue? We are not Python experts and working around Python issues is not necessarily something we can do. We would also prefer to not modify virtualenv in any way.


The issue is still present with Python 3.3 RC2. Log with RC2. What our next steps should be? We cannot provide Python 3.3 on travis because of this :( Maybe some Python hackers would be interested in helping us a little bit?


We use a different PPA for 3.3 this time, by the way.

carljm commented Sep 17, 2012 should be fixed in rc2, and on further review it seems unlikely to me that you are hitting, since the consensus on that bug seems to be that it's not a regression, so if your umask was set too strictly you'd have seen that problem on earlier Pythons as well (also, not likely that a PPA build would be broken in that way). So it seems likely that @tpievila 's analysis was incorrect.

Reviewing this thread, I don't see confirmation anywhere of the version of virtualenv/pip you are using, @michaelklishin ?

@carljm carljm reopened this Sep 17, 2012

pip 1.2.1, virtualenv 1.8.2.

carljm commented Sep 17, 2012

@michaelklishin I notice in your log that you're running virtualenv over top of an existing virtualenv directory; can you try rm -rf /home/travis/virtualenv/python3.3 and then rerun the virtualenv-creation? Also, can you run with -vvv? Thanks.

(If you're working on this now, I'm also carljm on Freenode in the #pip IRC channel.)

pnasrat commented Sep 17, 2012

Gives /usr/lib/python3.3/plat-i386-linux-gnu/ I'm betting that's not in sys.path

travis@precise32:~$ ls -lh /usr/lib/python3.3/plat-i386-linux-gnu/
total 32K
-rw-r--r-- 1 root root 5.9K Sep 17 14:57
drwxr-xr-x 2 root root 4.0K Sep 17 17:31 __pycache__
-rw-r--r-- 1 root root  19K Sep 17 14:58
pnasrat commented Sep 17, 2012

Note for self/others - has the patches, etc.


@mezzle suggests there is a patch in Quantal that our package did not include. We are waiting for another build to finish to try it out with supposedly full patch set.

@pnasrat pnasrat closed this Sep 17, 2012
@pnasrat pnasrat reopened this Sep 17, 2012
pnasrat commented Sep 17, 2012

oops fat fingered.

carljm commented Sep 17, 2012

@michaelklishin What is the value of sys.path inside the virtualenv? (i.e. /home/travis/virtualenv/python3.3/bin/python -c "import sys; print(sys.path)")

travis@precise32:~$ /home/travis/virtualenv/python3.3/bin/python -c "import sys; print(sys.path)"
['', '/home/travis/virtualenv/python3.3/lib/python3.3', '/home/travis/virtualenv/python3.3/lib/python3.3/plat-i386-linux-gnu', '/home/travis/virtualenv/python3.3/lib/python3.3/lib-dynload', '/usr/lib/python3.3', '/home/travis/virtualenv/python3.3/lib/python3.3/site-packages']
carljm commented Sep 17, 2012

Yes, @pnasrat 's hunch was correct; we need to add a new special case in virtualenv's to check if we're on a system using this multi-arch spec and add the system multi-arch-specific plat dir to sys.path. Thanks @michaelklishin for the debugging help.

pnasrat commented Oct 1, 2012

I'm guessing this is still occuring - @carljm do you have time for this, else I'lll try take a poke on the weekend

carljm commented Oct 3, 2012

@pnasrat If I have time it won't be until mid-next-week at the earliest; if you have time this weekend that'd be great.

pnasrat commented Oct 3, 2012

Sure - I should have time then, I'm at conference during the week.


Any progress on this? can someone who is not a virtualenv core contributor submit a fix? users are already asking for 3.3.

g2p commented Oct 14, 2012

@carljm I think it's more a question of symlinking the plat-$(MULTIARCH) dir when building the virtualenv.
The path is built correctly where I am (from Quantal's python3.3, which travis will get backported in due course), but the directory it refers to doesn't exist. It's part of the platform-dependent sys.path default, which exists before files are read (confirmed with python3.3 -ESsc 'import sys; print(sys.path)' inside and outside the virtualenv).

@pnasrat pnasrat closed this in 663a8c5 Oct 15, 2012

Were there any Virtualenv releases that include this fix? We still cannot provide Python 3.3 on because of this issue.

carljm commented Nov 5, 2012

I don't think any releases have included this fix yet. It could certainly be worth a bugfix release (@jezdez?) but in the meantime you should be able to use master virtualenv without negative consequences.

pnasrat commented Nov 6, 2012

+! for a release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.