segment-any-text / wtpsplit

Toolkit to segment text into sentences or other semantic units in a robust, efficient and adaptable way.
MIT License
758 stars 44 forks source link

Async - Skops import is failing #100

Closed MathiasExorde closed 1 year ago

MathiasExorde commented 1 year ago

I am trying with 1.2.1 and 1.2.3 but I have issues like:

1.2.1:

  File "/usr/local/lib/python3.10/site-packages/exorde/prepare_batch.py", line 10, in <module>
    from wtpsplit import WtP
  File "/usr/local/lib/python3.10/site-packages/wtpsplit/__init__.py", line 11, in <module>
    import skops.io as sio
ModuleNotFoundError: No module named 'skops.io'

or with just your latest version 1.2.3:


   from wtpsplit import WtP
  File "/usr/local/lib/python3.10/site-packages/wtpsplit/__init__.py", line 11, in <module>
    import skops.io as sio
  File "/usr/local/lib/python3.10/site-packages/skops/io/__init__.py", line 1, in <module>
    from ._persist import dump, dumps, get_untrusted_types, load, loads
  File "/usr/local/lib/python3.10/site-packages/skops/io/_persist.py", line 22, in <module>
    module = importlib.import_module(module_name, package="skops.io")
  File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/usr/local/lib/python3.10/site-packages/skops/io/_general.py", line 16, in <module>
    from ._trusted_types import (
  File "/usr/local/lib/python3.10/site-packages/skops/io/_trusted_types.py", line 17, in <module>
    SCIPY_UFUNC_TYPE_NAMES = get_public_type_names(module=scipy.special, oftype=np.ufunc)
  File "/usr/local/lib/python3.10/site-packages/skops/io/_utils.py", line 230, in get_public_type_names
    {
  File "/usr/local/lib/python3.10/site-packages/skops/io/_utils.py", line 234, in <setcomp>
    and (type_name := get_type_name(obj)).startswith(module_name)
  File "/usr/local/lib/python3.10/site-packages/skops/io/_utils.py", line 179, in get_type_name
    return f"{get_module(t)}.{t.__name__}"
  File "/usr/local/lib/python3.10/site-packages/skops/io/_utils.py", line 86, in get_module
    return whichmodule(obj, obj.__name__)
  File "/usr/local/lib/python3.10/site-packages/skops/io/_utils.py", line 49, in whichmodule
    if _getattribute(module, name)[0] is obj:
  File "/usr/local/lib/python3.10/site-packages/skops/io/_utils.py", line 24, in _getattribute
    obj = getattr(obj, subpath)
TypeError: __getattr__() missing 1 required positional argument: 'name'

I am using Python 3.10.11 Any ideas? I can't seem to simply import your lib.

bminixhofer commented 1 year ago

Hi, thanks for the issue. Python 3.10 is supported and tested in CI: https://github.com/bminixhofer/wtpsplit/actions/runs/5598764650/job/15165595701 so this is very strange.

Have you tried installing & importing skops separately i.e. pip install skops and python -c "import skops.io"?

MathiasExorde commented 1 year ago

It seems to work when imported seperately like you suggest. I am confused, it's probably compatibility issueswith other dependencies, no ideas. Everything is similar and should work but the import, when in my code, fails. I will inform here if I find a good explanation. Thanks for your work

bminixhofer commented 1 year ago

Sounds good, let me know if I can help. From the stacktrace it looks more like an skops issue, but quite hard to tell.

MathiasExorde commented 1 year ago

Ok so now it works on my software architecture. But it's still weird. I had to:

I would love to know if the relationship I identified with asyncio is real, or if it's a coincidental/dependency related with Python 3.10 & async behavior. In any case, it looks like an issue that comes up when the lib is imported in a 'complex' architecture.

bminixhofer commented 1 year ago

Great! Thanks for the rundown. I might see if I can repro it and find the root cause.

bminixhofer commented 1 year ago

It might also be related to #96

MathiasExorde commented 1 year ago

It might also be related to #96

It looks like it might be yes! I didn't see hints of recursion, but it seems likely that there is a common root cause to #96 and #100