Language install and/or book import fails.

[simjanos-dev]

I've got this bug report from someone on discord. He installs a language, and it shows success. Python does did throw an error. However he cannot switch to the language, and when refreshes the page, it does not list the language as an installed language. He also cannot import a book.

I have no idea what the problem could be.

@sergiolaverde0 Any idea what could be the problem?

pythonlogs.txt
webserver_logs.txt

[sergiolaverde0]

I see some nasty things here, and the two issues are probably unrelated.

Language install

I'm sure something is being downloaded and stored into the models folder. However installing the models themselves is silently failing and I don't see why. I suspect the user got annoyed at this point of the logs and proceeded to tinker manually looking for a fix, which backfired and let them to these lines:

2024-07-31 10:47:52 ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
2024-07-31 10:47:52 xx-ent-wiki-sm 3.7.0 requires spacy<3.8.0,>=3.7.0, but you have spacy 3.4.4 which is incompatible.

I just pulled and tested latest and it ships spacy 3.7.5 so I can't comprehend how did they manage to downgrade it, but it should be fixed by turning off the container, pulling the latest images and restarting it back.

I also see many Bottle errors and it being restarted several times, please ask the user if they are restarting the container or if this is the process crashing and restarting automatically, since it could be related to bottlepy/bottle#814.

Book import

The import of the book fails because somehow epub.read_epub(file) throws an exception, and deeper in the stack trace there is a mention to zipfile.py which is the root of the issue. It seems there is an attempt to retrieve an object from a dict with a OEBPS key that does not exist, is the file actually a .epub and is it working fine if the user tries to open it with a reader?

[simjanos-dev]

I suspect the user got annoyed at this point of the logs and proceeded to tinker manually

I don't think that's the case, I think he's not a tech savvy person (not sure). Could it maybe be an older python image? Also, he's on Mac.

Also a maybe important part:

I just updated and may have moved the directory
but the problem existed before I updated

I also don't see a .env file, but don't know what mac he's on and it's also a hidden file. I asked him what cpu he has. I also asked him to send me the ebook, or try an other one to confirm they are working.

I noticed the already installed languages in the log, but forgot to mention it. I was a bit tired. Also, he deleted the model folder, it did not fix it.

Thank you for your help!

[simjanos-dev]

He is using M1.

He sent me this. Am I crazy, or do I understand this correctly: the images with the latest tag are images with hashes that do not exist in linguacafe's repository? I cannot find them.

Edit: my python sha256 is also the same as his, but my webserver is different than his, but also different than the one that's on the ghcr.

(Probably I just misunderstood how hashes should work.)

[sergiolaverde0]

my python sha256 is also the same as his, but my webserver is different than his

Because the Python image is the same for everyone and Mac users must use virtualization until we release the native one, while the webserver is different for each platform. I pulled the ARM webserver image and it has matching hashes.

Apparently, those IDs are local only and will never match the remote registry, which I only just learned and I already hate it. To get hashes that match the registry you must run docker image ls --digests.

If they are using the latest image and the issue persists after restart, this is going to be troublesome to debug since I can't seem to reproduce on AMD64.

[simjanos-dev]

which I only just learned and I already hate it.

I'm glad that I'm not the only one.

[simjanos-dev]

If they are using the latest image and the issue persists after restart, this is going to be troublesome to debug since I can't seem to reproduce on AMD64.

They have the correct latest image hashes, however I think their .env file is not correct. But I thought without that it would make it not even start.

He said he even updated from an older ersion, but the issue was present before the update.

I feel so sad when I can't help someone fix something linguacafe related. :(

[simjanos-dev]

He reinstalled it completely, and it started working. Unfortunately it couldn't have been that simple, so he got his data back, after deleting the linguacafe folder, and running docker system prune. Have no idea how or why. But I'm happy it works.

Thank you for taking a look at it @sergiolaverde0!

[simjanos-dev]

I just pulled and tested latest and it ships spacy 3.7.5 so I can't comprehend how did they manage to downgrade it, but it should be fixed by turning off the container, pulling the latest images and restarting it back.

I think I may have found it: #332. Did we ever have version 3.4 - 3.5? If not, I have no idea how Turkish even worked so far. But I'm sure I tested it and worked when it was added.

[sergiolaverde0]

Did we ever have version 3.4 - 3.5?

We might, since we don't pin versions in pip. Maybe we should start doing so, even if only for the most important packages.

[sergiolaverde0]

For posterity sake: this is caused by installing Turkish from the extra languages section, and causes all default languages to break. Simply uninstalling Turkish does not fix it, users must uninstall completely, delete data, reinstall and restore. This is being tracked at #332.