search

standardebooks / tools

The Standard Ebooks toolset for producing our ebook files.
Other
1.42k stars 125 forks source link

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

Closed danneu closed 4 years ago

danneu commented 4 years ago

The culprit:

https://github.com/standardebooks/tools/blob/5ba244fea6c5cf64eeb3141cd8af5084492efc24/se/se_epub.py#L111-L112

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: https://github.com/standardebooks/tools/blob/5ba244fea6c5cf64eeb3141cd8af5084492efc24/se/se_epub_build.py#L94

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

danneu commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.