New builder

[cchalmers]

Don't merge yet. See diagrams/diagrams-pandoc#1.

[bergey]

Still to do:

• remove commented-out code in this branch
• update diagrams-doc to use new -builder (either via pandoc or via current Xml2Html)

Anything else?

[bergey]

I'd like to get this rebased & merged. If no one has come up with a better plan in nearly a year, it's good enough! My plan right now:

• update PRs to current master for diagrams-builder and all dependencies
• get those merged
• update diagrams-pandoc PR, including logic to pick format & Backend
• update the corresponding diagrams-doc PR

@cchalmers Does this sound right?

[cchalmers]

Sounds good. Sorry it's just been sitting here so long, there's so much stuff I want to do but nothing ever seems to get finished.

The PR to diagrams-lib can probably be discarded. In my head I wanted diagrams-pandoc to not have to depend on any backends by having all the diagram building logic necessary in diagrams-lib. But I found it pretty difficult to do this in general. Maybe it's something we can look at another time.

IIRC this and diagrams-pandoc where working and pretty much ready to merge. diagrams-doc still needs a fair amount of work (but I did get the pdf version of the manual building).

I'd be more than happy for you to take this over and I'll help any way I can. If not I'm sure I'll get round to it eventually :)

[bergey]

I thought it was my stalling that kept this from getting merged. I think I'll be OK getting -builder and -pandoc ready to merge. I'll probably need more help to understand everything that's going on in -doc.

Can we use the executables in diagrams-builder for -pandoc. I think they all have the same CLI, so users could install whichever Backends they need, and diagrams-pandoc could pick output format and Backend based on some combination of the pandoc output format and which builders are installed. We lose a bit of type safety, but the CLI doesn't change often.

That seems like the best experience for the user. They can get -cairo or -pgf if they need nice text, or stick to -rasterific or -svg if they're making web graphics and not on Linux. And they don't need to recompile diagrams-pandoc with a bunch of flags each time they add a builder.

Does this seem reasonable?

[cchalmers]

Sure, that could work. I guess we'd have to make sure the executables are in $PATH or something but it should work. There might be some issues with supporting things like snippets/extra imports/post-processing.

I'm tempted to say just get the minimum necessary done so we can get doc building and add any other features later. But I'll leave it up to you.

[byorgey]

Thanks for tackling this! All sounds good to me.

[byorgey]

Hey, what's the status of this? Anything I can help with here, now that I have some time?

[cchalmers]

Currently, my plans are:

1. Initial release of plots
2. Start making plots manual using the new builder / pandoc
3. Get diagrams-doc to use diagrams-pandoc

But if anyone else can work on it before that, that would be great.

My hope was to for things like diagrams-builder, diagrams-pandoc and ihaskell-diagrams to use multiple backends without having to use excessive CPP or need to reinstall every time you add a new backend but it turned out to be harder than I thought.

My first idea was to have a BackendBuild like class in diagrams-lib. I already tried this in diagrams/diagrams-lib#231. This did help a little but I still needed to import the backends to write backend specific code, but perhaps this can solved by adding more thing to the BackendBuild class. See my Diagrams.Pandoc attempt to get an idea what I mean.

@bergey's solution is to directly call the executables from diagrams-builder. This is probably a simpler solution and it won't need changes to -lib and probably doesn't need the changes I made here. It does require uses to build executables, keep them in $PATH and keep them up to date.

I'm leaning towards using the CLI to render diagrams for diagrams-pandoc, at least as a temporary solution. I'd like to hear your thoughts.