epubcheck plugin for Sigil

[Doitsu]

I've attached a new version that runs epubcheck 4.0.1 and is compatible with Python 3.4.x and Python 2.7.x.

The new version does not add any new functionality for checking ePub2 files and requires the Java 1.6 runtime (Java 1.7 recommended).

[Leonatus]

Hi, Doitsu! I've downloaded the new version but receive this message:

Running ePubCheck ... please wait

Traceback (most recent call last):

  File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 301, in <module>

    
sys.exit(main())
  File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 277, in main
    errorlog += unicode_str(data)
  File "C:\Program Files\Sigil\plugin_launchers\python\compatibility_utils.py", line 189, in unicode_str
    return p.decode(enc)
  File "C:\Python27\lib\encodings\utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 191: invalid start byte

Running ePubCheck ... please wait

It happens nothing else. No idea what Icould do.
Windows 10, 32 bit engine.

[KevinH]

FWIW, errors like this typically happens when latin1 or cp1252 chars are passed to python routines that are expecting utf-8 encodings. In this case, an error is being detected or generated by the plugin and it is the error message itself that is causing the issue as its contents are not utf-8.

You could run epubcheck via the command line and see what gets sent to std error to see what might be going on. To prevent this issue in future versions of the launcher I will tell it to 'replace' on error.

[Leonatus]

Thanks, KevinH! Unfortunately, I don't know how to run epubcheck via command line under Windows 10.
But I'll send the file where this occurs and further information to Doitsu. He will have a look at it.

[exaltedwombat]

Sigil 0.9 64 bit Windows 10
"Use bundled python"

What's going wrong? I got this working once!

Thanks

Status: failed

Traceback (most recent call last):
File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 134, in launch
target_script = __import__(script_module)
File "C:\Users\lp\AppData\Local\sigil-ebook\sigil\plugins\ePubTidyTool\plugin.py", line 27, in <module>
from ManualWordChecker import cManualWordCheck
File "C:\Users\lp\AppData\Local\sigil-ebook\sigil\plugins\ePubTidyTool\ManualWordChecker .py", line 9, in <module>
from bs4 import BeautifulSoup
ImportError: No module named 'bs4'
Error: No module named 'bs4'

[eschwartz]

Because you haven't installed BeautifulSoup4, I would assume.

[DiapDealer]

Sigil's bundled Python has no bs4 module. It has a modified version of BeautifulSoup called sigil_bs4 that's available to all plugins.

Developers who want plugins which have a bs4 dependency to work with Sigil's bundled python AND an external python installation will probably want to do something like:

try:
  from sigil_bs4 import BeautifulSoup
except ImportError:
  from bs4 import BeautifulSoup

This will have the advantage of still being able to work if and when Sigil's modified bs4 module ever becomes unnecessary in the future.

Just using:

from sigil_bs4 import BeautifulSoup

will probably work too, since the sigil_bs4 module is available to any external python installations (via the launcher framework), but has the disadvantage of possibly not working with earlier versions of Sigil, and potentially not working with future versions, if the special sigil_bs4 module ever becomes unnecessary.

Even if you have no plans to support external python interpreters with your plugin, it will still probably be a good idea to incorporate the try/except technique with (sigil_)bs4 for future-proofing. bs4 is currently the only "non-stock" python module that Sigil uses. If the constraints that force us to use it ever go away, we'd love to do away with it and replace it with the stock version. This technique will ensure your plugin's continued functionality in the event that happens.

Originally Posted by exaltedwombat

What's going wrong? I got this working once!

If you had it working once, I assume it's because you have a working external installation of Python with bs4 already installed. If that's the case, just uncheck "Use Bundled Python" and setup your external Python interpreter(s) in Manage Plugins.

[DNSB]

Yet another error message. Windows 10 x64. The error only occurs when I launch Sigil using Calibre's Open With plugin. Otherwise, I get the expected No problems found! message in Sigil's message box.

Status: failed

Traceback (most recent call last):
  File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 135, in launch
    self.exitcode = target_script.run(container)
  File "C:\Users\David\AppData\Local\sigil-ebook\sigil\plugins\EpubCheck\plugin.py", line 32, in run
    result = jarWrapper(*args)
  File "C:\Users\David\AppData\Local\sigil-ebook\sigil\plugins\EpubCheck\plugin.py", line 9, in jarWrapper
    process = Popen(list(args), stdout=PIPE, stderr=PIPE)
  File "subprocess.py", line 859, in __init__
  File "subprocess.py", line 1112, in _execute_child
FileNotFoundError: [WinError 2] The system cannot find the file specified
Error: [WinError 2] The system cannot find the file specified

[KevinH]

FWIW: I do not think opening an app like Sigil with its builtin python 3 in a python 2.7 program like Calibre would be generally a good idea.

KevinH

[DNSB]

Originally Posted by KevinH

FWIW: I do not think opening an app like Sigil with its builtin python 3 in a python 2.7 program like Calibre would be generally a good idea.

KevinH

Convenience trumps good idea 99% of the time.

[DiapDealer]

In addition to what KevinH said; there have been issues (for a long time) with the calibre OpenWith plugin and Windows and Sigil. The plugin "clears" the environment before launching Sigil (specifically) on Windows. Which means any environment variables (and possibly command-line args) that Sigil may get launched with are stripped beforehand. Perhaps you'd have better luck using the new(ish), built-in Open With feature of calibre.

Either way, I don't believe this particular error is something that can be "fixed" by the Sigil plugin developer.

[Doitsu]

Originally Posted by exaltedwombat

Sigil 0.9 64 bit Windows 10
"Use bundled python"

What's going wrong? I got this working once!

Thanks

Status: failed

Traceback (most recent call last):
File "C:\Program Files\Sigil\plugin_launchers\python\launcher.py", line 134, in launch
target_script = __import__(script_module)
File "C:\Users\lp\AppData\Local\sigil-ebook\sigil\plugins\ePubTidyTool\plugin.py", line 27, in <module>
from ManualWordChecker import cManualWordCheck
File "C:\Users\lp\AppData\Local\sigil-ebook\sigil\plugins\ePubTidyTool\ManualWordChecker.py", line 9, in <module>
from bs4 import BeautifulSoup
ImportError: No module named 'bs4'
Error: No module named 'bs4'

This is an error message for the ePubTidyTool developed by Calibuser. As for the solution, see DiapDealer's post.

Originally Posted by DNSB

Yet another error message. Windows 10 x64. The error only occurs when I launch Sigil using Calibre's Open With plugin. Otherwise, I get the expected No problems found! message in Sigil's message box.

Unfortunately, the epubcheck plugin only works if it's run directly from Sigil and not via Calibre.
BTW, if you just want to check your epub, download pagina EPUB-Checker, which comes with a nice GUI.

[davidfor]

Originally Posted by DiapDealer

In addition to what KevinH said; there have been issues (for a long time) with the calibre OpenWith plugin and Windows and Sigil. The plugin "clears" the environment before launching Sigil (specifically) on Windows. Which means any environment variables (and possibly command-line args) that Sigil may get launched with are stripped beforehand. Perhaps you'd have better luck using the new(ish), built-in Open With feature of calibre.

This is the code in the Open With plugin:

# As of v1.5.3 will no longer use subprocess because it does not work
# for users who have non-ascii library paths
# However we need a special case for Sigil which has issues with C runtime paths
DETACHED_PROCESS = 0x00000008
if external_app_path.lower().endswith('sigil.exe'):
    clean_env = dict(os.environ)
    del clean_env['PATH']
    subprocess.Popen(app_args_list, creationflags=DETACHED_PROCESS, env=clean_env)

That seems to only clear environment variable and the command-line arguments are whatever was put in the configuration.

This change was made in October 2012. That was done because of problems with the Sigil 0.5.9 beta. If the newer versions of Sigil is not likely to hit the same problem, then I can make the change.

[Doitsu]

@davidfor: I've just double-checked this issue with the latest 64bit Sigil 0.9.0 version and wasn't able to reproduce the bug described by DNSB.

The problem was most likely caused by an older Sigil version and or problems with external Python interpreters. I.e. there's nothing for you to fix.

@DNSB: Could you please provide the following information:

OS:
Sigil version:
Installed Python version(s):

Also please indicate whether you've installed the 32bit or 64bit versions of Sigil and Python.

[DiapDealer]

Not to counter your claim that it's working for you with v0.9.0, Doitsu, but... doesn't your plugin use the system PATH to locate the java executable? If the calibre OpenWith plugin cleans the PATH environment variable before launching Sigil (thanks @davidfor for the clarification, I couldn't remember the exact details). How will your (or any other Sigil plugin that relies on the system PATH to find an external program) be able to function if PATH is cleaned beforehand?

Regarding whether or not Sigil still suffers from the issue with c runtime paths that it's predecessors had, I have no real idea at this time.