Could not create new "InitEnv"

[alexey.lomaka@…]

Creating and Initializing Project
 Installing default wiki pages
Initenv for 'd:\svn\trac\work' failed.
'ascii' codec can't decode byte 0xc0 in position 26: ordinal not in range(128)
Traceback (most recent call last):
  File "build\bdist.win32\egg\trac\admin\console.py", line 424, in do_initenv
    WikiAdmin(self.__env).load_pages(pages_dir)
  File "build\bdist.win32\egg\trac\wiki\admin.py", line 159, in load_pages
    @self.env.with_transaction()
  File "build\bdist.win32\egg\trac\db\api.py", line 77, in transaction_wrapper
    fn(ldb)
  File "build\bdist.win32\egg\trac\wiki\admin.py", line 169, in do_load
    filename=filename, page=page))
  File "build\bdist.win32\egg\trac\util\translation.py", line 37, in gettext_noop
    return safefmt(string, kwargs)
  File "build\bdist.win32\egg\trac\util\translation.py", line 30, in safefmt
    return string % kwargs
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc0 in position 26: ordinal not in range(128)

[cboos (the original one ;-) )]

Funny, the two modifications of yesterday were not mine… I suppose someone is wanting me to get some progress on #1890 ;-)

[Christian Boos]

Replying to cboos (the original one ;-) ):

Funny, the two modifications of yesterday were not mine… I suppose someone is wanting me to get some progress on #1890 ;-)

Read my mail in the interval… problem understood :-)

[Remy Blank]

That shouldn't prevent you from working on #1890, right? :-)

[anonymous]

Replying to rblank:

That shouldn't prevent you from working on #1890, right? :-)

No, #1890 is an another situation. This is a different errors.

I think I have error because I have wrong Python connect for Database.

I have pysqlite-2.5.6.win32-py2.5.exe, but this installation I think not finished correctly, because I did not see "Finish" button. Package from SQLite with command "python seput.py install" i could not seput because it built with Visual Studio 2003.

[Remy Blank]

Possible fix.

[Remy Blank]

I suspect this happens when the path to imported wiki pages contains non-ASCII characters, but I don't seem to be able to reproduce this issue, at least on Linux. A possible fix is shown in 9571-path-to-unicode-r10043.patch​, but to be honest I have no idea if this is the right approach.

Feedback, testing and possibly more information by the OP would be appreciated.

[Christian Boos]

As the filename derives from:

                    pages_dir = pkg_resources.resource_filename('trac.wiki', 
                                                                'default-pages') 
                    WikiAdmin(self.__env).load_pages(pages_dir)

(in admin/console.py)

I suspect that here the egg cache is located in C:\Users\<non ascii username>\App Data\Python-eggs (see ​http://peak.telecommunity.com/DevCenter/PkgResources#platform-utilities), and I suspect that in this case, the present problem will only be the first of a long list…

[Remy Blank]

Ah, right, I had forgotten about the egg cache. So maybe it's not worth fixing the issue then, and just document that all the working paths of Trac (installation path, environment path, egg cache path, any others?) must only contain ASCII characters?

[Christian Boos]

Replying to rblank:

So maybe it's not worth fixing the issue then, and just document that all the working paths of Trac (installation path, environment path, egg cache path, any others?) must only contain ASCII characters?

Maybe, yes. But I would nevertheless first try your patch with a PYTHON_EGG_CACHE pointing to a non-ascii directory, and if everything just works…

[Remy Blank]

Replying to cboos:

But I would nevertheless first try your patch with a PYTHON_EGG_CACHE pointing to a non-ascii directory, and if everything just works…

I'm still unable to reproduce this exact issue. I manage to get an exception e.g. in os.path.isdir(), but not the exact location as shown in the description. So I definitely need some help from the OP. Alexey, can you please test the patch and let us know:

• If your PYTHON_EGG_CACHE contains non-ASCII characters.
• If the patch solves the issue for you.

[Christian Boos]

The path_to_unicode() could be simply:

def path_to_unicode(path):
    return to_unicode(path, sys.getfilesystemencoding())

But I'm dubious the patch would help here, as filename is already supposed to be in unicode, as we do a line = to_unicode(line, encoding) very early, before command dispatching.

No, the problem is different, unfortunately it's more deeply rooted in Python:

>>> u"  %(page)s imported from %(filename)s" % dict(page="ete", filename=u"été")
u'  ete imported from \xe9t\xe9'
>>> u"  %(page)s imported from %(filename)s" % dict(page="été", filename=u"ete")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0x82 in position 0: ordinal not in range(128)

[anonymous]

Подтверждаю. При выполнении

trac-admin.exe D:\WWW\tracroot\nsi initenv

возникает

Initenv for 'd:\svn\trac\work' failed.
'ascii' codec can't decode byte 0xc0 in position 26: ordinal not in range(128)

Видимо по причине того, что Python-Eggs\trac-0.12-py2.5-win32.egg-tmp\trac\wiki лежит в профиле пользователя, имя которого содержит кириллицу. Справился просто. На другой машине, где имя учетной записи состоит из латиницы (ну и конечно присутствует Python, Traс и т.д.) создал окружение, а потом просто перенес на сервер.

[Christian Boos]

Follow-up to 13:

…

> >>> u"  %(page)s imported from %(filename)s" % dict(page="été", filename=u"ete")

Not sure anymore what point I was trying to make, but of course the above will fail as page is a str that can't be converted implicitly to unicode. I was under the impression that the order of parameters to % would matter, but it's not the case.

[Remy Blank]

Replying to anonymous:

Видимо по причине того, что Python-Eggs\trac-0.12-py2.5-win32.egg-tmp\trac\wiki лежит в профиле пользователя, имя которого содержит кириллицу. Справился просто. На другой машине, где имя учетной записи состоит из латиницы (ну и конечно присутствует Python, Traс и т.д.) создал окружение, а потом просто перенес на сервер.

Automatic translation by Google of the paragraph above:

Probably due to the fact that Python-Eggs\trac-0.12-py2.5-win32.egg-tmp\trac\wiki is in the user profile name that contains the Cyrillic alphabet. Handled easily. On another machine where the account name consists of Latin (and of course there is Python, Tras, etc.) has created an environment and then simply transferred to the server.

So the issue here is indeed PYTHON_EGG_CACHE. Using a path_to_unicode() function for displaying paths to the user is probably ok.

[Christian Boos]

I tested this on Windows with user "joé", and then got the same traceback as the OP when running initenv. For (filename, page) I have:

('C:\\Users\\jo\xe9\\Python-eggs\\Trac-0.13dev_r10794-py2.7.egg-tmp\\trac\\wiki\\default-pages\\CamelCase', u'CamelCase')

So Remy's approach of reporting the paths with path_to_unicode is good. I've tested the patch 9571-path-to-unicode-r10043.patch​ and it indeed fixed the problem.

There's a typo in the patch though:

trac/util/text.py

@@ -82 +82 @@
     """Convert a filesystem path to unicode, using the filesystem encoding."""
     if isinstance(path, str):
         try:
-            return unicode(text, sys.getfilesystemencoding())
+            return unicode(path, sys.getfilesystemencoding())
         except UnicodeDecodeError:
             return unicode(path, 'latin1')
     return unicode(path)

[Remy Blank]

Great, thanks for testing! I'm going to go through all the other command providers and see if there are any other candidates for path_to_unicode(), then I'll apply the patch.

[Remy Blank]

I have found a few more instances. Patch applied in [10811].

[killwindows@…]

C:\Documents and Settings\kin>trac-admin C:\trac initenv
Traceback (most recent call last):
  File "c:\Python27\Scripts\trac-admin-script.py", line 8, in <module>
    load_entry_point('Trac==1.0', 'console_scripts', 'trac-admin')()
  File "c:\Python27\lib\site-packages\pkg_resources.py", line 318, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "c:\Python27\lib\site-packages\pkg_resources.py", line 2221, in load_entry_point
    return ep.load()
  File "c:\Python27\lib\site-packages\pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "c:\docume~1\kin\locals~1\temp\easy_install-gkozad\Trac-1.0-py2.7-win32.egg.tmp\trac\admin\console.py", line 29, in <module>
  File "c:\docume~1\kin\locals~1\temp\easy_install-gkozad\Trac-1.0-py2.7-win32.egg.tmp\trac\env.py", line 41, in <module>
  File "c:\docume~1\kin\locals~1\temp\easy_install-gkozad\Trac-1.0-py2.7-win32.egg.tmp\trac\versioncontrol\__init__.py", line 1, in <module>
  File "c:\docume~1\kin\locals~1\temp\easy_install-gkozad\Trac-1.0-py2.7-win32.egg.tmp\trac\versioncontrol\api.py", line 29, in <module>
  File "c:\docume~1\kin\locals~1\temp\easy_install-gkozad\Trac-1.0-py2.7-win32.egg.tmp\trac\web\__init__.py", line 4, in <module>
  File "c:\Python27\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()
  File "c:\Python27\lib\mimetypes.py", line 259, in read_windows_registry
    for ctype in enum_types(mimedb):
  File "c:\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)

My login name is kin, only ASCII characters.

[Christian Boos]

Replying to killwindows@…:

...
  File "c:\Python27\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()

My login name is kin, only ASCII characters.

This has nothing to do with the login name, rather you have some non-ASCII suffix registered in your Windows registry. This is a known issue in Python (​pythonbug:9291). The quickquest "fix" in your case would be to delete the offending entry in your registry (look in HKEY_CLASSES_ROOT\MIME\Database\Content Type).

(for the reason why you get a UnicodeDecodeError for a call to encode, see UnicodeDecodeError#encode).

[killwindows@…]

Replying to cboos:

This has nothing to do with the login name, rather you have some non-ASCII suffix registered in your Windows registry. This is a known issue in Python (​pythonbug:9291). The quickquest "fix" in your case would be to delete the offending entry in your registry (look in HKEY_CLASSES_ROOT\MIME\Database\Content Type).

(for the reason why you get a UnicodeDecodeError for a call to encode, see UnicodeDecodeError#encode).

You were right. This issue wasn't even related to trac. There was some bug in one of Python libraries, I found some fix for that and applied and it worked. What a wonderful thing is when you can easily change *.py (after those dead dlls).

[killwindows@…]

Btw. Why did it install in c:\docume~1\kin\locals~1\temp\easy_install-gkozad\ ? I don't like that. Sometimes I erase temp\ totally.

[Christian Boos]

Replying to killwindows@…:

Btw. Why did it install in c:\docume~1\kin\locals~1\temp\easy_install-gkozad\ ? I don't like that. Sometimes I erase temp\ totally.

See TracInstall#SettingupthePluginCache.