Closed thetechnodino closed 1 year ago
Why is the issue titled "buku server", when the stacktrace is showing the error in the main library file?
Try running buku
instead of bukuserver
– it should produce the same error with a much shorter stacktrace.
(…On the other hand, there's no reason to import readline
when buku
is imported as a library instead of being run via CLI; so there's that as well.)
So I suppose there's really 2 issues here:
buku
fails to ~init CLI~ import some libraries on Windowsbuku
tries to ~init CLI~ import readline
even when it's not run as __main__
…Regarding the 1st one – it could just be that pyreadline
is missing from setup.py
dependencies on Windows (and I'm guessing readline
is not available). Have you tried installing it manually (e.g. pip install --user pyreadline
)?
Also I'm guessing that pyreadline
dependency should be actually updated to pyreadline3
, seeing as it's been stale since 2015.
Tested it out on my work laptop (which has Windows installed). Conclusions:
buku
or bukuserver
on Windows, two extra dependencies are needed (should be added to setup.py
) – pyreadline
and certifi
(on Linux, readline
is used instead of the former, and in place of certifi
a system-wide file is used)pyreadline
can be safely replaced with pyreadline3
(at least as far as I tested)readline
is only ever used in main()
, so there's no need to import it globally (this addresses the 2nd issue)pyreadline
to pyreadline3
, the output changed (as in, it still printed garbled characters instead of changing background, but in lower amounts) – this could mean that contributing a fix to pyreadline3
would resolve this problemLexofLeviafan: Thanks for responding so promptly. We agree: this is a bug, for sure. Thanks for updating post label to 'BUG".
John
Is the length of an error stack trace of any consequence apart from shorter is easier to read?? If buku and buku server contain the same error what is the point in running buku?? Short or long the stack trace would show the error. I was running buku server because I did not want to use CLI.
Finally, the post is titled"buku server" because I encountered the error while running the server. I think the title is accurate: buku server is missing a python module. The error stack trace was provided to identify the specifics.
The error is happening in the library, because the bug is in the library, and the place where it needs to be fixed is the library (…or in the dependencies of the library). The fact you encountered the error while running the GUI is merely a happenstance, and running the CLI or even trying to import the file as a library will cause the same error because the bug has nothing to do with GUI.
Your suggestion of contributing a fix to pyreadline3 is beyond my current capability in Python or whatever language required to fix. Please feel free to contribute the required fix.
This is a separate issue, which would take more effort to fix than this one; rather than suggesting for anyone specific to fix it, I'm merely stating that it exists (and may need a separate discussion in case someone would be willing to put in an effort to fix it).
Just to make sure I understand. The specific issues, modules missing, can be fixed apart from fixing the pyreadline3 issue.
Is this bug being added to the buku/buku server bug list for resolution?
Thanks
John Payne
630-815-2989 | www.pde-usa.net [3]
Sola Deo Gloria
On 2023-01-20 16:27, LeXofLeviafan wrote:
Your suggestion of contributing a fix to pyreadline3 is beyond my current capability in Python or whatever language required to fix. Please feel free to contribute the required fix.
This is a separate issue, which would take more effort to fix than this one; rather than suggesting for anyone specific to fix it, I'm merely stating that it exists (and may need a separate discussion in case someone would be willing to put in an effort to fix it).
-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>
[1] https://github.com/jarun/buku/issues/664#issuecomment-1398973766 [2] https://github.com/notifications/unsubscribe-auth/ALM5AVOF5SXU65ZTBF6RM2LWTL7NTANCNFSM6AAAAAAUA5LFUU [3] http://www.pde-usa.net
To put it plainly: I knew the software was "buggy". GUI or not: there was an issue. Was the issue connected to the GUI code? I did not know and did not say.
You asked 2 question, I answered both.
Q: why was I running the GUI based version? A:(No interest in using CLI)
Q: why was the post titled as it was? A: (A description of the issue: I was using the GUI version and stack trace showed a missing module).
A module, obviously, is part of the library of the software in use. Recognizing a missing module is recognizing that the library is problematic and that the library needs fixing.
Fine by me if you do not want to to deal with pyreadline3.
John Payne
630-815-2989 | www.pde-usa.net [3]
Sola Deo Gloria
On 2023-01-20 16:20, LeXofLeviafan wrote:
Is the length of an error stack trace of any consequence apart from shorter is easier to read?? If buku and buku server contain the same error what is the point in running buku?? Short or long the stack trace would show the error. I was running buku server because I did not want to use CLI.
Finally, the post is titled"buku server" because I encountered the error while running the server. I think the title is accurate: buku server is missing a python module. The error stack trace was provided to identify the specifics.
The error is happening in the library, because the bug is in the library, and the place where it needs to be fixed is the library (...or in the dependencies of the library). The fact you encountered the error while running the GUI is merely a happenstance, and running the CLI or even trying to import the file as a library will cause the same error because the bug has nothing to do with GUI.
-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>
[1] https://github.com/jarun/buku/issues/664#issuecomment-1398959584 [2] https://github.com/notifications/unsubscribe-auth/ALM5AVL4YUZSCJ35N4P73RTWTL6QPANCNFSM6AAAAAAUA5LFUU [3] http://www.pde-usa.net
not sure where to start,
@thetechnodino can you try related pr
is there an actual error on window?
Yes
…The error still exists.
I "installed" 4.7.1 (or at least I tried to install it). Looks like all the requirements were met (second code block) So the server should run (first code block)??
I could not find (using netstat among others) evidence that the server was listening at port 5001. Did the program install?
====First Code Block=== When i tried to start the server:
<PS C:\Users\John> bukuserver run --host 127.0.0.1 --port 5001 bukuserver : The term 'bukuserver' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1
+ CategoryInfo : ObjectNotFound: (bukuserver:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException>
===Second Code Block===
<PS C:\Users\John> pip3 install "buku[server,reverse_proxy]" Requirement already satisfied: buku[reverse_proxy,server] in c:\python310\lib\site-packages (4.7.1) WARNING: buku 4.7.1 does not provide the extra 'reverse_proxy' Collecting flask-reverse-proxy-fix@ https://github.com/rachmadaniHaryono/flask-reverse-proxy-fix/archive/refs/tags/v0.2.2rc1.zip Using cached https://github.com/rachmadaniHaryono/flask-reverse-proxy-fix/archive/refs/tags/v0.2.2rc1.zip Preparing metadata (setup.py) ... done Requirement already satisfied: beautifulsoup4>=4.4.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (4.11.1) Requirement already satisfied: cryptography>=1.2.3 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (39.0.0) Requirement already satisfied: urllib3>=1.23 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.26.14) Requirement already satisfied: html5lib>=1.0.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.1) Requirement already satisfied: appdirs>=1.4.3 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.4.4) Requirement already satisfied: arrow>=0.12.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.2.3) Requirement already satisfied: cffi>=1.9.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.15.1) Requirement already satisfied: click>=6.7 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (7.1.2) Requirement already satisfied: Flask-Admin>=1.5.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.6.0) Requirement already satisfied: Flask-API>=0.6.9 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (2.0) Requirement already satisfied: Flask-Bootstrap>=3.3.7.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (3.3.7.1) Requirement already satisfied: flask-paginate>=0.5.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (2022.1.8) Requirement already satisfied: Flask-WTF>=0.14.2 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.1.1) Requirement already satisfied: Flask<2.0,>=1.0.2 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.1.4) Requirement already satisfied: idna>=2.5 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (3.4) Requirement already satisfied: itsdangerous>=0.24 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.1.0) Requirement already satisfied: Jinja2>=2.10.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (2.11.3) Requirement already satisfied: markupsafe==2.0.1 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (2.0.1) Requirement already satisfied: packaging>=16.8 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (23.0) Requirement already satisfied: pyasn1>=0.2.3 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (0.4.8) Requirement already satisfied: pycparser>=2.17 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (2.21) Requirement already satisfied: requests>=2.21.0 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (2.28.2) Requirement already satisfied: six>=1.10.0 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.16.0) Requirement already satisfied: Werkzeug>=0.11.15 in c:\python310\lib\site-packages (from buku[reverse_proxy,server]) (1.0.1) Requirement already satisfied: python-dateutil>=2.7.0 in c:\python310\lib\site-packages (from arrow>=0.12.1->buku[reverse_proxy,server]) (2.8.2) Requirement already satisfied: soupsieve>1.2 in c:\python310\lib\site-packages (from beautifulsoup4>=4.4.1->buku[reverse_proxy,server]) (2.3.2.post1) Requirement already satisfied: wtforms in c:\python310\lib\site-packages (from Flask-Admin>=1.5.1->buku[reverse_proxy,server]) (3.0.1) Requirement already satisfied: dominate in c:\python310\lib\site-packages (from Flask-Bootstrap>=3.3.7.1->buku[reverse_proxy,server]) (2.7.0) Requirement already satisfied: visitor in c:\python310\lib\site-packages (from Flask-Bootstrap>=3.3.7.1->buku[reverse_proxy,server]) (0.1.3) Requirement already satisfied: webencodings in c:\python310\lib\site-packages (from html5lib>=1.0.1->buku[reverse_proxy,server]) (0.5.1) Requirement already satisfied: certifi>=2017.4.17 in c:\python310\lib\site-packages (from requests>=2.21.0->buku[reverse_proxy,server]) (2022.12.7) Requirement already satisfied: charset-normalizer<4,>=2 in c:\users\john\appdata\roaming\python\python310\site-packages (from requests>=2.21.0->buku[reverse_proxy,server]) (2.1.1)>
Did the program install?
Requirement already satisfied: buku[reverse_proxy,server]
This means nothing happened – it's reusing previously installed packages (identified by name).
Incidentally, you don't need reverse_proxy
unless you're trying to combine multiple sites into one or something.
in c:\python310\lib\site-packages
Such testing is better done in a venv. (TLDR: create a Python sandbox with virtualenv venv
– this requires virtualenv
module; activate on Windows with venv\Scripts\activate
, deactivate with deactivate
)
…Also it may be better to use CMD on Windows, at least when checking.
So the server should run (first code block)??
A successfully started (Flask-based) server should print out something in the lines of
Running on http://127.0.0.1:5001/ (Press CTRL+C to quit)
P.S. I'm normally running bukuserver from a venv as well, with a script (which can be done on Windows, too)
@LeXofLeviafan: AFIK, the software did not install. No comment when I run the bukuserver run command. Server not listening at port 5001.
I will try your suggestions. The reverse proxy version is what installed when I ran: pip install. There is a note that the software does not contain the reverse proxy server.
John
No, I mean it literally: your pip install command had no effect because you already have a package named buku
installed (which I don't even have to guess, because the traceback in OP is pointing at the installed file C:\Python310\lib\site-packages\buku.py
). Every line that says "Requirement already satisfied" means nothing was changed there.
The reverse proxy version is what installed when I ran: pip install. There is a note that the software does not contain the reverse proxy server.
Here's a line copy-pasted directly from your previous comment:
<PS C:\Users\John> pip3 install "buku[server,reverse_proxy]"
This is a command to install a package named buku
with two extras: server
and reverse_proxy
.
The warning is printed because the most recent release does not have an extra named reverse_proxy
, though my point was that you had likely no reason to install it in the first place.
P.S. Just tried it on my work machine; the most recent release cannot be installed from PyPI so it didn't work anyway. As for the reason you can't run the bukuserver
script directly – it's not in your PATH so your system (PowerShell?) can't find it; this can be circumvented by either using a venv (all modules installed in it are in PATH when the venv is active), adding the folder with it to PATH (the suggestion is printed out when you install a module globally), or using -m
to invoke it (i.e. on Windows I'm running py -m virtualenv venv
to create a venv).
can you try python3 -m bukuserver
or windows equivalent of that?
Buku 4.7; Windows 11: Windows Terminal; Python 3.10.9 installed. Buku 4.7 installed without any errors.
bukuserver run --host 127.0.0.1 --port 5001
generates console outputTraceback (most recent call last): File "C:\Python310\lib\site-packages\buku.py", line 57, in
import readline
ModuleNotFoundError: No module named 'readline'
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "C:\Python310\Scripts\bukuserver-script.py", line 33, in
sys.exit(load_entry_point('buku==4.7.1', 'console_scripts', 'bukuserver')()) File "C:\Python310\Scripts\bukuserver-script.py", line 25, in importlib_load_entry_point
return next(matches).load()
File "C:\Python310\lib\importlib\metadata__init__.py", line 171, in load
module = import_module(match.group('module'))
File "C:\Python310\lib\importlib__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "C:\Python310\lib\site-packages\bukuserver\server.py", line 19, in
import buku
File "C:\Python310\lib\site-packages\buku.py", line 59, in
import pyreadline as readline # type: ignore
ModuleNotFoundError: No module named 'PYREADLINE'