Python interpreter (QGIS WIndows) cannot read C libraries included in installed packages #59775
Comments
walking-the-talk
added
the
Bug
|
This looks similar to an issue you reported yourself last year ? |
|
Yes, I suppose it is. I have worked out a bit more about what the problem is as you can see. But I have already gone beyond my capabilities and have been stuck for a year... I guess I can close the other one. |
|
Interested / intrigued to see an apparently similar issue just reported: And specifically
I have, for the sake of argument tried the same relevant 'tests':
No change. I'm not going to be as simple minded as to suggest they are caused by the same problem, but it would be convenient if they required the same fix... I understand that spelling isn't very sxy for everyone so my identified issue not being taken seriously compared with things that get in the way of processing data. I'm trying not to get frustrated, but forgive me if I come across that way. I would rather be using QGIS than trying to fix it :-) @m-kuhn - you deleted your comment I think, but I did use the VERBOSE_FIND - and the results are in the original post. That's why I opened this issue as it provides a better (I hope) description of the problem compared with the one I just closed that had sat unattended for a year. I understand that spelling isn't very sxy for everyone so my identified issue is perhaps not being taken seriously compared with things that get in the way of processing data. I'm trying not to get frustrated, but forgive me if I come across that way after first suggesting the feature in August 2022 (with an outline route-map) and then creating the plugin and releasing it as a proof-of-concept (that works in Linux but not Windows). I would rather be using QGIS than trying to fix it :-) But rather than just complain, I'm prepared to help if I can, and I appreciate assistance that is offered, to make QGIS better. |
|
Yes, I realized you already reported that you've checked I would look into the enchant init code (stacktrace) and possibly add some debug statements and compare what happens in the osgeo shell case and what in the qgis py console case. |
|
@walking-the-talk I guess this issue is not related to #59776. |
Thanks for this suggestion @m-kuhn - I'm not sure if this is what you meant: I used traceback in init.py and placed a call in I have left OSGEO4W shell:Compare with QGIS Console:I understand what it's doing, but I have no idea what it means. |
|
@m-kuhn - I have done as requested, so wonder if you or anyone else might have any clues from that, or advice on how better to describe the issue / bug-trace. To my untrained eye it looks like QGIS python interpreter can locate the libraries, but pyenchant cannot then access the Dictionaries, which are in the same path - I don't know whether locating the libraries is the same as allowing pyenchant (or the python interpreter) to utilise them. Like I said before I'm beyond my competence but willing to help... @jef-n - your input on the difference in behaviour in OSGEO4W shell and the QGIS python interpreter could be key to this. There are MinGW packages available for Enchant but I don't know how to utilise them. If they could be incorporated into the QGIS installation process for Windows would that circumvent the problem? Is there a way to simulate that on my pc to test the idea (I would need very clear instructions as I am not familiar with compilers) Many thanks in anticipation of your help. |
|
Sorry, I don't know the internals of enchant. |
|
I am struggling to stay afloat here, but I've been swimming through the code and it looks like init.py is calling _enchant.py to do the linkages to the C libraries. I have checked in that file and (lack of) error reports indicates that the module can actually find the C library (the VERBOSE output previously posted shows that positively too). I debug-printed the paths in _enchant and can also confirm that pyenchant is using 'from_package' - which I take it means that it is using the C Libraries from the site_packages rather than looking elsewhere: Pyenchant works in QGIS running on Ubuntu natively and WSL2, it also works in another python environment on my PC with Jupyter lab and a Windows Shell (both versions of Python - 3.9.12 and 3.12.5). And of course in the OSGEO4W shell with python 3.12.5 that QGIS runs... I am unable to produce anything that differentiates between the QGIS interpreter and the shell that relates to pyenchant but it does show (as in the previous post), which might be where the problem lie: The evidence I have gathered to date still points to the QGIS python interpreter, not pyenchant, and I have no idea how to help further. I have spent many hours chasing my tail, not being competent in this area but trying to help find clues. I am unable to make any more sensible contribution to this. I genuinely need help at a more fundamental level than trying to debug someone else's package(s). Please tell me I'm wrong on this. I think all I have revealed is my incompetence. But perhaps it would similar to asking a member of the public to fly a plane to Australia - they might make a reasonable passenger, but you wouldn't want them in the front seat. |
|
Did you open an issue on enchant side too? For the enchant community it will be easier to guess assumptions made within enchant library which may not be met when qgis loads its python interpreter. Or unlock additional levels of debug information. |
|
Is the GRASS plugin/provider installed and/or loaded? That comes with libiconv-2.dll and libintl-8.dll too - those might be incompatible with the ones shipped with pyenchant. |
|
@m-kuhn : Enchant issue: @jef-n , I disabled the GRASS8 and GRASS GIS provider plug-ins on the clean QGIS profile I have been testing with - no change in behaviour (restarted before testing). pyenchant has libiconv-2.dll version 1.16 and libintl-8.dll version 0.19.8.1 included in the mingw/bin folder This is the full copy of the QGIS installation details <style type="text/css"> p, li { white-space: pre-wrap; } </style>
Active Python plugins |
|
The mingw dlls shipped with pyenchant are older, than the ones with GRASS (uninstalling GRASS or renaming the grass directory makes enchant load) |
|
@jef-n thanks for updating your comment, much more helpful - however, I'm afraid I can't replicate that: if I rename the GRASS folders (in both OSGEO4W and qgis-ltr folders to make sure) I am unable to change the outcome of previous tests. after For the sake of curiosity, I copied the five dlls that overlap between GRASS and enchant into the mingw/bin folder to see if that helped. It didn't - same result an empty list of languages in the QGIS console, and a full language list in OSGEO4W shell - at least it didn't break enchant though. So maybe it was an outdated packaging thing rather than a dependency on a particular version of the dlls.
The pyenchant docs do outline a different way to install on Windows, 'taking advantage of mingw', but I was unable to complete this task as the the devil is in the detail: https://pyenchant.github.io/pyenchant/install.html#using-mingw - I don't have the skills / capacity to learn how to do this. Which also means I don't know the implications of trying to get the mingw package of enchant https://packages.msys2.org/packages/mingw-w64-x86_64-enchant incorporated into OSGEO4W - that's the reason I haven't filed a request - it might be a completely unreasonable one. Maybe I've wasted 18 months by trying to get pyenchant to work on windows and I shouldn't have started from here - it seemed like a good idea at the time. I am actively trying to improve QGIS rather than just complaining about things not working as I would like. |
What is the bug or the crash?
In Windows, the QGIS Python console reports that an installed python package is not functional, despite it working as expected in OSGEO4W shell. I thought it might be caused by included C libraries not being readable by QGIS python interpreter. In this case it is pyenchant which requires the libraries to be available (in subfolder of C:\OSGeo4W\apps\Python312\Lib\site-packages\enchant\data\mingw64).
Pyenchant has a VERBOSE_FIND function to check that the libraries are located
OSGEO4W shell and QGIS python console (same output):
OSGEO4W shell:
but QGIS python console:
QGIS python version doesn't see the spelling dictionaries, which are stored in
C:\OSGeo4W\apps\Python312\Lib\site-packages\enchant\data\mingw64\share\enchant\hunspell
which means that pyenchant throws errors as there is no dictionary to work with...
It seems to be a QGIS issue not a pyenchant one.
This is preventing me from creating a functioning spell checker plugin for QGIS in Windows, and therefore potentially integrating spell-check functionality as a core feature...
#49934
https://plugins.qgis.org/plugins/QGISpell/
Please note that I am a QGIS user, not a developer, so please don't pile-in on my ignorance or general stupidity - I am very well aware of it already. But I would greatly appreciate help from developers who might be able to unlock this - my earlier attempts have led to dead-ends, probably because I don't know the right question to ask.
Steps to reproduce the issue
On a Windows PC open OSGEO4W shell and install pyenchant:
behaviour in OSGEO4W shell (expected):
start qgis and open the python console
Output from Python Console:
Versions
Supported QGIS version
New profile
Additional context
This problem does not occur in (QGIS for) Linux providing that libenchant is installed through the package manager - as per the installation instructions for pyenchant. Which means that a Widows PC with WSL2 and Ubuntu (for example) can run pyenchant and the QGISpell plugin works...
The text was updated successfully, but these errors were encountered: