Bug 404103 – dev-python/virtualenvwrapper-3.0: ImportError: No module named virtualenvwrapper.hook_loader

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Vladislav Poluhin 2012-02-16 12:31:57 UTC]

Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named virtualenvwrapper.hook_loader
virtualenvwrapper.sh: There was a problem running the initialization hooks. If Python could not import the module virtualenvwrapper.hook_loader, check that virtualenv has been installed for VIRTUALENVWRAPPER_PYTHON=/usr/bin/python and that PATH is set properly.

$ equery files virtualenvwrapper | grep 'virtualenvwrapper/'
/usr/lib64/python2.7/site-packages/virtualenvwrapper/hook_loader.py
/usr/lib64/python2.7/site-packages/virtualenvwrapper/project.py
/usr/lib64/python2.7/site-packages/virtualenvwrapper/user_scripts.py
/usr/lib64/python3.1/site-packages/virtualenvwrapper/hook_loader.py
/usr/lib64/python3.1/site-packages/virtualenvwrapper/project.py
/usr/lib64/python3.1/site-packages/virtualenvwrapper/user_scripts.py

Where is __init__.py?

Reproducible: Always

Steps to Reproduce:
1. Add `source /usr/bin/virtualenvwrapper.sh` to ~/.bashrc
2. Create new bash session

[Comment 1 Nicolas Pinto 2012-02-17 04:26:55 UTC]

Confirmed. 

Fixed here:
https://github.com/npinto/sekyfsr-gentoo-overlay/blob/master/dev-python/virtualenvwrapper/virtualenvwrapper-3.0.ebuild

[Comment 2 Vladislav Poluhin 2012-02-17 05:44:47 UTC]

My ebuild with doc:
https://bitbucket.org/nuklea/overlay/src/aa51e610e672/dev-python/virtualenvwrapper/virtualenvwrapper-2.11.1.ebuild

[Comment 3 Dirkjan Ochtman (RETIRED) 2012-02-17 09:47:57 UTC]

I'm not sure the naive solution (as in Nicolas' ebuild) is the best here, as we also see similar problems with other ebuilds (e.g. bug 404189).

[Comment 4 Vladislav Poluhin 2012-02-17 10:35:55 UTC]

(In reply to comment #1)
> Confirmed. 
> 
> Fixed here:
> https://github.com/npinto/sekyfsr-gentoo-overlay/blob/master/dev-python/virtualenvwrapper/virtualenvwrapper-3.0.ebuild

Really insane solution. What about code in __init__.py?

[Comment 5 Ewoud Kohl van Wijngaarden 2012-02-17 11:05:20 UTC]

Maybe something broke in setup.py with 3.0 and it's really an upstream bug? From the build log:

Skipping installation of /var/tmp/portage/dev-python/virtualenvwrapper-3.0/temp/images/3.1/usr/lib64/python3.1/site-packages/virtualenvwrapper/__init__.py (namespace package)

[Comment 6 Arfrever Frehtes Taifersar Arahesis 2012-02-17 17:40:46 UTC]

distutils.eclass in EAPI >=4 enforces proper handling of namespaces. You can use EAPI="3" if you aren't prepared to properly handle namespaces.

[Comment 7 Priit Laes (IRC: plaes) 2012-03-01 09:43:35 UTC]

(In reply to comment #6)
> distutils.eclass in EAPI >=4 enforces proper handling of namespaces. You can
> use EAPI="3" if you aren't prepared to properly handle namespaces.

EAPI="3" workaround fixes this issue \o/

[Comment 8 Patrick Lauer 2012-03-15 16:58:42 UTC]

fixed distutils.eclass instead, not in the mood to arfrever around.

[Comment 9 Ewoud Kohl van Wijngaarden 2012-03-16 10:50:24 UTC]

I don't see any difference nor did portage offer me install an updated version of virtualenvwrapper so please re-open it until it's properly fixed.

[Comment 10 JTRiley 2012-03-16 14:28:29 UTC]

(In reply to comment #9)
> I don't see any difference nor did portage offer me install an updated
> version of virtualenvwrapper so please re-open it until it's properly fixed.

It's an eclass fix so there's no updated ebuild. Just make sure you sync and then re-emerge the current virtualenvwrapper ebuild.

[Comment 11 Ewoud Kohl van Wijngaarden 2012-03-19 10:23:00 UTC]

I did rsync, but I guess the mirror wasn't up to date yet. Synced now and re-merged which seems to work.