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 ;-)

[cboos]

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 :-)

[rblank]

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.

[rblank]

Possible fix.

[rblank]

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.

[cboos]

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...

[rblank]

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?

[cboos]

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...

[rblank]

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.

[cboos]

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с и т.д.) создал окружение, а потом просто перенес на сервер.

[cboos]

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.

[rblank]

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.

[cboos]

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)

[rblank]

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.

[rblank]

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