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).

Hi, Doitsu! I've downloaded the new version but receive this message:
It happens nothing else. No idea what Icould do.
Windows 10, 32 bit engine.

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.

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.

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'

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

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:
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:
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.

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.

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.

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.

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.

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

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.

This is the code in the Open With plugin:

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.

@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.

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.