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