New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pyenchant not working within QGIS environment #311
Comments
No idea :( Is QGIS hard to install ? I'm asking in case anyone wants to try and reproduce the bug |
QGIS is very easy to install - https://qgis.org/en/site/forusers/download.html - using the LTR - there is and .msi installer that can be used with default settings... After installation there is a way to install additional python packages using the OSGeo4W shell (should be available on your start menu) - this will run the qgis installed version of python - and then use pip -m install pyenchant As highlighted above the site-packages are installed in the Roaming folder for Python39 (the version used by QGIS... Thanks. I find it hard to believe that QGIS has no inbuilt spell checker and I'm trying to pull together a plugin that will work... I have a way of generating QPlainTextEdit widgets so I'm a step closer... |
|
Thanks. I carefully followed the guide and checked that the dictionaries were installed before posting (in the previous screengrab you will see that the hunspell folder exists). I followed the subsequent tutorials, I have now installed pyenchant on another windows machine with QGIS 3.22 installed and run further tests on the existing installation (without obvious intervention from me, Enchant now works). I can get Enchant to work from within the OSGeoW shell (i.e. it calls the version of Python used by QGIS). However it does not work on either machine when using the Python console within QGIS - using the same command sequence. Does this point more clearly to QGIS being the issue? Is part of the package not being 'exposed' to QGIS (I'm not a python expert as you can tell!) To address your second point, I appear to have used EN_US rather than en_US, but that doesn't seem to be a material issue as far as I can see - enchant appears to pick up en_US when EN_US is requested:
Thanks for your help so far. |
That isn't the QGIS Python install. import sys
print(sys.executable) in both OSGeo4W Shell and QGIS Python console.
Don't have a Windows machine at hand, but I think it must say something like: |
Thanks for following up on your comments from StackExchange. Agreed that is not the QGIS install, but it is the location that OSGeo4W installs these site packages when using the shell and If it were to be installed within the QGIS install (in my case print(sys.executable) from OSGeo4W: As mentioned at StackExchange (https://gis.stackexchange.com/questions/473944/) I have also checked the available paths using print(sys.path) – both OSGeo4W shell and the QGIS Console include |
I think that folder is for a system-wide Python install. Maybe the pip version used to install it was a system-wide one.
Yes. It is a kind of Python virtual environment, and must be in that way.
Yes, but the problem doesn't seem to be related with pyenchant but with the enchant C library wrapped in it, since it is not installed inside QGIS environment. I don't know where it is installed but maybe you can make its path available through Windows PATH (not PYTHONPATH) environment variable. |
Thanks - really appreciate your assistance. My first attempt to install pyenchant was to try using (so it now sits alongside all the main packages such as pandas geopandas etc) No joy. I added the folder No joy. I tried your suggestion of No joy. I'm going way beyond my competence here, but it looks like _enchant.py is the ctypes wrapper and appears to construct the 'connections' to the relevant folders (extract from lines 33-38 of the code):
I'm not surprised there is no package within OSGeo4W - there has been no apparent interest in spell checking within QGIS anyway (an observation rather than criticism!) I'm ALMOST relieved that it isn't an obvious error that I've made... but still frustrated that I've fallen over before even being able to get the proof-of-concept to work. |
Yes, the So, try to edit your installed print(f'{enchant_lib_path = }') line between 170 and 171 (before If you can print the path to the library returned in both consoles we can see what the problem is. Also, you will be sure which pyenchant package are they calling. |
Thanks - your patience with my level of competence is admirable :-) and not even patronising me when I pointed out the ctype wrapper location (which you'd clearly already worked out). I had previously been going through the code and the thrown errors to see if I could make some sense of it, and I'd spotted the commented code in So the path to the library is exactly the same on both QGIS Python console and OSGeo4W Shell:
In an attempt to be helpful, I changed line 117 to Which gives the following output:
Again this is the same in both consoles - nothing obviously amiss. |
Ok, so this is something with QGIS Python interpreter, or just something inside the QGIS Python console interface. I wrote a QGIS plugin to run Python files without the console. It is called Puentes. Can you install it? Write a file, anywhere, called something like test_enchant.py, with the following code: # test_enchant.py
import enchant
b = enchant.Broker()
plog(f'{b.list_dicts() = }')
d = enchant.Dict('en_US')
plog(f'{d.check('enchant') = }') Open Plugins menu, Puentes, Configure, and open the test_enchant.py file. In the same menu, click on Run. |
Nice Bridge! If I've installed it correctly, I still have the same problem... I hope the error in line 94 of your Puentes code is caused by enchant failing and not anything I have done? Puentes Log: 2024-01-12T16:48:08 INFO Configured to run: C:\Users\Chris\AppData\Roaming\QGIS\QGIS3\profiles\default\python\expressions\test_enchant.py So it can't find any dictionaries and throws exactly the same errors as QGIS console in enchant Python Error log:
[side-note - double quotes are required in Still scratching my head... |
So it is a not a console problem. The Python interpreter can't find it.
The traceback must be logged in the same tab and not raise the exception to QGIS. If you can add a issue including the Python version (from QGIS About window) I can see how to fix the traceback call.
Sorry, that error was mine. I don't have a Windows machine and am not testing this. I will see if it work in a Debian machine. |
Well, it works out-of-the-box in debian, just installing python3-enchant. |
No problem, no need to apologise for being so helpful and giving a sample script for testing - I was just making sure that anyone else testing this would be able to follow (or not pick up a false error). Hence calling it a side-note :-) Good that it works on debian - starting to narrow down some avenues of thought. Thanks for confirming that it is a pyenchant / windows / QGIS triumvirate! |
It seems to me strange that both paths are the same but QGIS can't read the dictionaries. The library seems to be loaded. You can try to set Windows environment variables at hand. See that the last directory in the path is the I don't know how to test enchant steps after the library load. |
I've added that specific I have checked that it can be read using We appear to have reached a limit here - unless the pyenchant developers can shed some light on testing enchant after the library load, we are stuck. I will see if I can find any answers / ask more useful or directed questions of QGIS developers around the Python interpreter on Windows (given that the enchant package for debian works in QGIS as you have demonstrated). Thanks for all your help - none of which is wasted, even though we haven't found the prize yet :-) |
I wonder... qgis/QGIS#54491 If you can get pyenchant to work on debian version of QGIS, which I think it running a more recent version of python (hence your plugin Puentes needing a back-port to version <3.10), maybe there is an (undocumented?) issue with QGIS python interpreter doing anything more than seeing mingw64 libraries? I know that's arm-waving vague statement, but maybe more food for thought... |
Whether due to the interpreter embedded in the QGIS executable, or for some other reason, it was always difficult to link libraries within QGIS in Windows. That's why there is no apparent consensus on how to install them. And therefore, the best solution that I see possible is to include enchant (and even better python3-enchant) package in the OSGeo4W repository. My recommendation is to complete a feature request ticket in the OSGeo4W trac system (an OSGeo UserID is required), asking about its possible inclusion or requesting help about your current installation. |
Thanks for this suggestion - seems a prudent move irrespective of the underlying issue - awaiting approval of OSGeo Userid to log the request. |
Environment
Python version: 3.9
Operation system: Windows 10 64 bit
Additional context
QGIS 3.28 - I am trying to import enchant module to spell check data within QGIS. The problem might be QGIS related and I will raise an issue there, but I thought I would start here...
Steps to Reproduce
used pip install --target=path/to/python/QGIS pyenchant
It has installed and is working as expected using the command prompt in Windows
However, when accessing it through the Python Console in QGIS, although it appears to import enchant (it can run the help command), I get the following error when running the test code to enchant.request_dict("EN_US"):
No dictionaries / languages are available when I try to list them using the broker (but no errors appear when running that code)
Expected behaviour
just no error would be nice! I have a Python script that needs enchant, but can't get to test that if it can't identify a Dict()
Additional context
in Windows console
Weirdly that looks like Python is running via Inkscape (there are multiple versions of Python on my machine!) - I tried copying the enchant-2 folder to lib in my python39 folder, but no joy (that was a stab in the dark)
Thanks for any help you can provide (even it is just to point me towards QGIS as the culprit)
The text was updated successfully, but these errors were encountered: