bzr 2.5.0-2 has site.py(o) from setuptools which prevents `bzr selftest` to run

Bug #968189 reported by Alexander Belchenko on 2012-03-29
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar Windows Installers
High
Unassigned

Bug Description

I have quite serious problem with latest standalone installer bzr 2.5.0-2. For some reason there is included setuptool's site.py(o) module instead of standard python's site.py, and setuptools's site.py does not work correctly in py2exed form:

C:\work\Bazaar\plugins\qbzr>make test
bzr selftest -s bp.qbzr
bzr: ERROR: exceptions.ImportError: Couldn't find the real 'site' module

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 920, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1131, in run_bzr
  File "bzrlib\commands.pyo", line 673, in run_argv_aliases
  File "bzrlib\commands.pyo", line 695, in run
  File "bzrlib\cleanup.pyo", line 136, in run_simple
  File "bzrlib\cleanup.pyo", line 166, in _do_with_cleanups
  File "bzrlib\builtins.pyo", line 4110, in run
  File "bzrlib\tests\__init__.pyo", line 41, in <module>
  File "site.pyo", line 73, in <module>
  File "site.pyo", line 38, in __boot
ImportError: Couldn't find the real 'site' module

bzr 2.5.0 on python 2.6.6 (Windows-XP-5.1.2600-SP3)
arguments: ['bzr', 'selftest', '-s', 'bp.qbzr']
plugins: acad[0.8.0], bzrtools[2.5.0], colo[0.3.1dev], explorer[1.3.0dev],
    fastimport[0.14.0dev], find_branches[unknown], format1[unknown],
    git[0.6.7], launchpad[2.5.0], qbzr[0.23.0dev], rewrite[0.6.4dev],
    scmproj[0.6.2dev], svn[1.2.1], tiplog[0.0.5dev], undelete[0.2.0],
    x_bit[1.0.0]
encoding: 'cp1251', fsenc: 'mbcs', lang: None

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.
make.EXE: *** [test] Ошибка 4

Which is quite bad because it completely blocks selftest.

Alexander Belchenko (bialix) wrote :

bzr 2.5.0-1 does not have this problem.

Changed in bzr-windows-installers:
status: New → Confirmed
importance: Undecided → High
Martin Packman (gz) wrote :

Gah, the fault of dulwich. I was previously hacking it every time to remove all references to setuptools, but was bored of that so tried a different approach, see r214 on bzr-windows-installers.

Short of automating the manual patching I was doing previously or rewriting the build process to be less insane, I'm not sure I've got any ideas.

Vincent Ladeuil (vila) wrote :

> Short of automating the manual patching I was doing previously or rewriting the build process to be less insane, I'm not sure I've got any ideas.

Both ideas sound worthwile :)

The osx installer already handle patches in an ad-hoc way may be you can start from there ?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers