No module named qurator when callling eynollah CLI

[lmarti-dev]

I get the following error when trying to call eynollah in the windows terminal:

Traceback (most recent call last):
  File "C:\src\python3\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\src\python3\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Users\Moi4\Desktop\code\misc\eynollas\venv\Scripts\eynollah.exe\__main__.py", line 4, in <module>
ModuleNotFoundError: No module named 'qurator' 

The error happens regardless of the arguments.

I installed eynollah (and nothing else) in a fresh virtual environment with Python 3.10.11.

If that helps, here are the windows specs:

Edition Windows 10 Home Version 22H2 Installed on ‎05/‎05/‎2021 OS build 19045.4780 Experience Windows Feature Experience Pack 1000.19060.1000.0

[kba]

We have removed the qurator namespace recently in #133.

Can you try pip uninstall eynollah, git pull and pip install . to see if the error persists?

[lmarti-dev]

Unfortunately, building directly from the repo gives me the following error

Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [39 lines of output]
      Traceback (most recent call last):
        File "C:\Users\Moi4\Desktop\code\misc\eynollas\venv\lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 353, in <module>
          main()
        File "C:\Users\Moi4\Desktop\code\misc\eynollas\venv\lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "C:\Users\Moi4\Desktop\code\misc\eynollas\venv\lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 118, in get_requires_for_build_wheel
          return hook(config_settings)
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\build_meta.py", line 332, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=[])
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\build_meta.py", line 302, in _get_build_requires
          self.run_setup()
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\build_meta.py", line 503, in run_setup
          super().run_setup(setup_script=setup_script)
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\build_meta.py", line 318, in run_setup
          exec(code, locals())
        File "<string>", line 1, in <module>
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\__init__.py", line 117, in setup
          return distutils.core.setup(**attrs)
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\_distutils\core.py", line 146, in setup
          _setup_distribution = dist = klass(attrs)
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\dist.py", line 283, in __init__
          _Distribution.__init__(self, dist_attrs)
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\_distutils\dist.py", line 279, in __init__
          self.finalize_options()
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools\dist.py", line 635, in finalize_options
          ep(self)
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools_ocrd\_integration\setuptools.py", line 27, in get_ocrd_tool_version
          dist.metadata.version = _get_version()
        File "C:\Users\Moi4\AppData\Local\Temp\pip-build-env-fzdy36xu\overlay\Lib\site-packages\setuptools_ocrd\_get_version.py", line 11, in _get_version
          return json.load(fp)["version"]
        File "C:\src\python3\lib\json\__init__.py", line 293, in load
          return loads(fp.read(),
        File "C:\src\python3\lib\json\__init__.py", line 346, in loads
          return _default_decoder.decode(s)
        File "C:\src\python3\lib\json\decoder.py", line 337, in decode
          obj, end = self.raw_decode(s, idx=_w(s, 0).end())
        File "C:\src\python3\lib\json\decoder.py", line 355, in raw_decode
          raise JSONDecodeError("Expecting value", s, err.value) from None
      json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build wheel did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

because windows fails to recognize the ocrd-tool.json symlink. I've simply overwritten the symlink with the actual file and eynollah now works in the command line! (at least the --help command does work)

[kba]

because windows fails to recognize the ocrd-tool.json symlink. I've simply overwritten the symlink with the actual file and eynollah now works in the command line! (at least the --help command does work)

Ah, right, Windows does not like those. And yes, that would have been my recommended workaround. The symlink is only relevant at build time, once it has been installed, no symlinks are involved.

@mikegerber Would it be possible to extend setuptools-ocrd to dereference the symlink OS-independently at build time? Or to look for the ocrd-tool.json in the package directory directly?

[mikegerber]

@mikegerber Would it be possible to extend setuptools-ocrd to dereference the symlink OS-independently at build time?

That's a bit of a hack :\ How does the top-level ocrd-tool.json look like in Windows? If it's easy to do, I'll consider it.

Or to look for the ocrd-tool.json in the package directory directly?

Then it would need to find the package directory first :\

Note that I do most of my work in WSL and I would 100% recommend using that over native Windows.

[mikegerber]

@lmarti-dev What git did you use here? Or is it included in the Python install from e.g. the Microsoft Store?

(Not my platform and I need some more information to maybe fix this in setuptools-ocrd (the component that fails here))

[mikegerber]

(This was already an issue with setup.py as I understand it.)

[mikegerber]

@mikegerber Would it be possible to extend setuptools-ocrd to dereference the symlink OS-independently at build time?

That's a bit of a hack :\ How does the top-level ocrd-tool.json look like in Windows? If it's easy to do, I'll consider it.

In a checkout using the official Windows version of git, the file looks like this:

C:\Users\b-mg106\Downloads\eynollah>more ocrd-tool.json
src/eynollah/ocrd-tool.json

At least this looks easy enough to resolve "by hand".

[cneud]

Hi @lmarti-dev and thank you for your interest in Eynollah!

I am sorry but we can not support Windows (or Mac) and even if the build and executing --help work, there may still occur other issues further down the line when running Eynollah. As mentioned by @mikegerber, it works nicely in WSL which we strongly recommend to use, alternatively Docker should also do the trick.

I'll leave this open for a couple of days more for feedback and otherwise hope for your understanding when I close this issue.

[lmarti-dev]

Thank you both for the extensive feedback. Unfortunately, installing WSL bluescreens my computer, so that's a no go for me.

I've been trying to run Eynollah beyond the --help command, but for now I've run into multiple issues not related to my using windows, but rather due to loading the models (I get a bad marshal data error which seems to be related to this issue. -- even though I'm using python 3.7 with Eynollah. I'm more familiar with pytorch than keras, so I don't know whether it's worth trying to fix it.

@mikegerber I'm not sure by what you mean by "what git"? I installed Eynollah by git cloning and pip installing the repo, if that's what you're asking.

[cneud]

Since we switched to src layout, there should be no more issues with the qurator namespace, so closing here.

Unfortunately we won't support windows, but perhaps the instructions for using Eynollah with Docker can help.