se build over-aggressively fails if dc:identifier is not a standardebooks.org url

[danneu]

The culprit:

tools/se/se_epub.py

Lines 111 to 112 in 5ba244f

	if "<dc:identifier id=\"uid\">url:https://standardebooks.org/ebooks/" not in self.metadata_xml:
	raise se.InvalidSeEbookException

I'm using a few components of the se kit to create a similar project that targets a different language. As such, my identifier doesn't point to standardebooks.org, but a different project url.

I could see this hard-error being intentional if the build step adds additional standardebooks-specific metadata that only makes sense in a standardebooks project, but I didn't see anything like that when I skimmed the code.

Edit: there's actually this, which may be the reason behind the hard-error:

tools/se/se_epub_build.py

Line 94 in 5ba244f

output_filename = identifier.replace("https://standardebooks.org/ebooks/", "").replace("/", "_")

Though this info can also be read from the project folder name, among other options.

[danneu]

There's also other SE-specific changes that the build-steps entail like writing (and thus overwriting) the <title> in the various generated .svgs. But those are easy to deal with. se build seems like the only real blocker.

It's of course straightforward to fork the project to swap out the SE stuff which makes sense on a longer time scale for a serious "sister"-project since that's simply going to be more ergonomic for people.

On the other hand, se create-draft -> modify the generated files like the colophon -> se split-file -> se clean -> and then se build is a great toolchain for building ebooks in general in any language that works today and gets you 90% of the way there. And I think only a few genericizing tweaks to the build steps would be necessary (like allowing custom dc:identifier) to remove the remaining hurdle.

For example, I've been working on my own typogrify and semanticate steps for another language which are easy to inject into that chain without forking the whole chain.

[danneu]

Despite what the issue title lets on, this would actually require more invasive change to be done right.

I think the most realistic solution is for interested parties to just fork the project or, as I've done, write some lightweight transformation tooling on top of the se kit.

[acabal]

Yeah I think I agree. I was thinking about it yesterday and the toolkit is too specific to the project right now to be able to white label it easily. That might be a goal for future development but it would take some time.