win32_data_files() and libenchant*.dll

54 views
Skip to first unread message

G.Cordeiro

unread,
Jun 8, 2011, 2:56:11 AM6/8/11
to pyenchant users
Hello,
I'm pakaging a python app in Windows 7 using py2exe (latest version)
and Python2.7
This is how I haldle pyenchant in my 'setup.py':

try:
import enchant
except ImportError:
pass
else:
from enchant import utils as enchantutils
DATA_FILES += enchantutils.win32_data_files()

I found this function very useful for py2exe, but I think that this is
generating some problems in my .exe because of the name of the
library:

In '_enchant.py' I read the line:

mypath =
"os.path.dirname(utils.get_resource_filename("libenchant.dll"))"

However, the win32_data_files function reports this:

>>> win32_data_files()
[('', ['C:\\Python27\\lib\\site-packages\\enchant\
\libenchant-1.dll', ...

Am I making anything wrong? Or maybe it necesary to rename the library
in '_enchant.py' to 'libenchant-1.dll'?

Thanks in advance,
Gonçalo

G.Cordeiro

unread,
Jun 8, 2011, 1:48:21 PM6/8/11
to pyenchant users
Replying myself:

There is no problem on EXE compilation and the bundled library.
However running my app raises this error:

Traceback (most recent call last):
File "MainEditor.py", line 30, in <module>
File "WordForge\Editor\modules\TUview.pyo", line 32, in <module>
File "WordForge\Editor\modules\Preference.pyo", line 35, in <module>
File "enchant\__init__.pyo", line 91, in <module>
File "enchant\_enchant.pyo", line 66, in <module>
File "os.pyo", line 420, in __setitem__
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe7' in
position 420: ordinal not in range(128)

I believe that this is caused by my username (gonçalo) when searching
for 'C:\Utilizadores\gonçalo\AppData\roaming\enchant',
where other dicts are supposed to be placed by users. So I've tried
those changes:

if sys.platform == "win32":
# Add our bundled enchant libraries to DLL search path
try:
mypath = "." (<--- line 66)

and below:
for e_path in _e_path_possibilities():
if e_path is not None:
try:
e_path = "libenchant-1.dll" (<--- new line)
e = cdll.LoadLibrary(e_path)

This makes pyenchant to work as expected, but the dicts have to be
located in the bundled 'share\enchant\myspell\' dir,
which is not writable by normal users when installed; so they can't
add new dicts to the system (inside %APPDATA%).

Trying to package this with Pyinstaller 1.5 but got the same
traceback, so I guess that this is pyenchant issue:
Fails to work with non ASCII named paths.

Cheers,
Gonçalo

Ryan Kelly

unread,
Jun 8, 2011, 9:17:51 PM6/8/11
to pyencha...@googlegroups.com, G.Cordeiro

Hi Gonçalo,


> I believe that this is caused by my username (gonçalo) when searching
> for 'C:\Utilizadores\gonçalo\AppData\roaming\enchant',
> where other dicts are supposed to be placed by users. So I've tried
> those changes:
>
> if sys.platform == "win32":
> # Add our bundled enchant libraries to DLL search path
> try:
> mypath = "." (<--- line 66)
>
> and below:
> for e_path in _e_path_possibilities():
> if e_path is not None:
> try:
> e_path = "libenchant-1.dll" (<--- new line)
> e = cdll.LoadLibrary(e_path)
>


What version of PyEnchant are you using? Those line numbers don't seem
to match up with the contents of _enchant.py in the latest version
(v1.6.5).


Thanks,

Ryan

--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
ry...@rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details

signature.asc

Ryan Kelly

unread,
Jun 12, 2011, 7:03:44 PM6/12/11
to Gonçalo Cordeiro, pyencha...@googlegroups.com

Redirecting this back to the list for archival purposes, response below.

On Sun, 2011-06-12 at 23:36 +0200, Gonçalo Cordeiro wrote:
> Em 10-06-2011 01:38, Ryan Kelly escreveu:
> > On Fri, 2011-06-10 at 01:24 +0200, Gonçalo Cordeiro wrote:
> >>> No problem at all. Can you confirm whether the latest version works as
> >>> you expect?
> >>
> >> As far as I have seen, all is working as expected using the latest
> >> version. It only remains a minor issue related to folders renaming
> >> inside a py2xe dist dir: If I rename it (e.g. to 'bin', before
> >> packaging), spellchecking stops working. But not sure about the origin
> >> of this, maybe my code or py2exe...
>
> However, I can reproduce the issue and it seems to happen only if I name
> the folder that contains the EXE (and the mentioned enchant folders) as
> 'bin'. In this case, pyenchant doesn't found any dict.
>
> The app expects to find some data dirs one level up, so I create a root
> app dir with all data dirs and a 'bin' one, which includes the EXE and
> all the expected libraries.
>
> If I rename 'bin' to whatever else, e.g. 'bin2' (not only the default
> 'dist'), it works like a charm.
>
> Note that the only broken operation seems to be spellchecking, but I
> can't say whether this depends on py2exe or pyenchant.
>
> I'll rename that dir as whatever else, the problem is solved by doing
> this, but the 'bin' issue is a bit strange case.


I'm note sure, but I can have a guess at what's going on here.

The underlying enchant library contains a lot of magic to determine the
relative path to the plugin dlls, library files etc. This is called the
"prefix" directory.

The win32 version of this code contains an explicit section that checks
whether the prefix ends in "bin". If so, it steps up one more level.
There is even a comment that says "Strip off 'bin' subfolder if present"
so it's definitely doing this on purpose.

This is probably a workaround for applications installed in the unix
style using something like mingw, where the executable goes in a "bin"
directory while the libraries go in a "lib" directory.

So, you're running into an unfortunate side-effect. Renaming the
top-level directory to "bin" tricks enchant into thinking that it's
installed in a unix-style layout. It calculates its prefix directory
incorrectly and then it can't locate its supporting libraries.

If you really want to use the name "bin" for the directory containing
your application, you could try moving the "bin/lib" directory up one
level. So you'd have "bin" containing the executables, and "lib"
containing the enchant support files. If my guess is right, this should
allow enchant to work OK.

Or like you said, you could just pick a name other than "bin" :-)


Cheers,

signature.asc
Reply all
Reply to author
Forward
0 new messages