Closed NaruZosa closed 2 years ago
Other images you may prefer :)
Thank you for your feedback.
I must confess I don't want to change much to this project, as it fits my own needs the way it is right now.
click
, I don't really want to change it. If you really want to avoid using click
and generate_epub.callback
, it is possible to copy the code inside jncep.cli.epub.generate_epub
into your own (async) function. In order to call it, you will need to create a Trio async context using trio.run(partial(f, *args, **kwargs))
. What I can do as well is put the content of that generate_epub
function inside its own function (ie without the click
-related code) so if you are fine with what it does, you wouldn't have to copy it.loguru
: I don't really want to change the logging. That being said, I didn't know about it so thank you for telling me.
click
callback before a command is executed, so if your code doesn't pass through there (which should be the case if you call generate_epub.callback
) there should not be an issue (besides redirecting the logging
logs to loguru
).
Hi there!
I've just created https://github.com/NaruZosa/jncep_webui after changing my web app to import and use jncep directly instead of using subprocess.call.
There were a few hiccups along the way, but the biggest was jncep using Click, as Click is designed in such a way that it's difficult for other modules to import a function that uses Click decorators, unless you're importing from another Click CLI. Took a couple of hours to find this workaround: https://github.com/pallets/click/issues/40#issuecomment-326014129
Would you be open to accepting a pull request that replaces Click with argparse while retaining the same features and user experience? Argparse is in the stdlib, so no additional requirements, and it would also make it possible to easily make a GUI using Gooey (I'm willing to create a pull request for this as well) and also makes it possible to create unit testing with better coverage, which is difficult to do with Click.
For logging, I highly recommend changing to Loguru. It also supports coloured logging, and is very powerful and super simple to use. It is not part of stdlib, but the only dependencies for it art colorama (already present in jncep) and win32setctime, which have no dependencies of their own, and would allow dropping rich, commonmark and pygments, if I've read the jncep source correctly. I noticed that your logging levels are a bit unusual, and this seems to be because you want to have trace logging. Loguru has extra levels by default, and trace is among these. The levels available by default are trace, debug, info, success, warning, error and critical. It's also easy to add extra levels, and everything is highly customisable. The basic logger is set up with just
from loguru import logger
, then you can uselog.trace("Message")
etc. Check out my app.py for an example of the lack of boilerplate. It may look a little messy due to the InterceptHandler class, logger.remove() and the basicConfig parts, but these are only there to disconnect the jncep logger and redirect it to Loguru, normally these wouldn't be present.Just to clarify, I'm not asking you to make these changes yourself. You've done a great job with jncep, and I'm just wondering if you'd be willing to accept a pull request for these changes before I make them :)
Also, let me know if you like the image I've used for jncep_webui and would like to use it with jncep instead. You're more than welcome to do so, and I can make a new one for jncep_webui. Alternatively, let me know what sort of image you would like for jncep and I can make one. It'd be made with Dalle, so any art style is fine (this was made with an oil painting style).