resolves #276 try to use KindleGen/EPUBCheck binary from $PATH

[slonopotamus]

No description provided.

[mojavelinux]

You are correct to only do this if the KINDLEGEN env var is not set. That gives the user the ability to avoid the use of the kindlegen on the PATH, which is an important for security, I would think.

[ysb33r]

I would like that besides finding it in the environment there is another way of locating the binary i.e. via an attribute. This allows external downloaders to set the path. For instance in Gradle we are forced to run this out of process i.e. another JVM because of the environmental variable, but if there is a way of setting it, then we can utilise in-process generation.

[slonopotamus]

You mean, via document attribute? That makes sense, doing things in-process (especially, on JRuby) is definitely preferrable.

[slonopotamus]

@mojavelinux could suggest an attribute name for this so we don't acidentally clash with other asciidoctor machinery? Something like ebook-kindlegen-binary-path?

[slonopotamus]

@ysb33r I think, the order of preference will be:

1. env var
2. attribute
3. kindlegen gem
4. PATH

[slonopotamus]

After more thinking, I want to make attribute higher priority than env var. Case: user has env var defined and calls asciidoctor-epub3 -a ebook-kindlegen-binary-path=/path/to/kindlegen <book>. It is clear that their intent is to override global behavior for this particular invocation.

[slonopotamus]

@mojavelinux are there any security concerns about passing kindlegen path through document attributes? Is there any alternative way to pass settings to Asciidoctor::Epub3::Packager that bypass the document itself?

I see that Converter::initialize accepts opts hash, maybe that's a better way?

[slonopotamus]

@ysb33r I've updated PR with document attributes to specify KindleGen/EPUBCheck executable location, but still waiting for @mojavelinux to review this.

And it deserves to be documented, I think.