1. 70

  2. 18

    Pandoc is one of the handful of opensource projects I love:

    • It usually does what I expect
    • I find all types of uses for it in my daily work
    • The author is kind and welcoming to new contributors
    • It allows me to use markdown as my composing hammer
    1. 4

      Conversely, installing this in Arch requires like 100 other Haskell packages (I know it only shows 75 but I believe some dependencies have other Haskell dependencies).

      1. 7

        That is unfortunate, pandoc releases static binaries which work great in my experience, https://github.com/jgm/pandoc/releases/download/3.0/pandoc-3.0-linux-amd64.tar.gz

        1. 7

          The AUR has a pandoc-bin package.

          1. 5

            I don’t see the problem. pandoc is very clearly an integration project, integrating many document formats, providing a unified AST, etc.

            It is a very reasonable path to pick high-quality and accepted dependencies in the ecosystem over implementing your own in this case. With that eye, I’m actually surprised that it’s just 100.

            1. 3

              You cannot blame Pandoc: someone decided that each Haskell library had to be its own separate Archlinux package, and there is not much you can do about it.

              This is infortunate and only works because there are very few Haskell packages, so the chances of having version conflicts are low. But it is still annoying to run pacman and have hundreds of packages to update.

              1. 1

                It’s been a while since I touched it but my recollection is that pacman is still really fast with lots of little files and packages, so no biggie. Is that still correct, please?

                1. 1

                  Performances are fine (but it might be that my NVME disk is doing all the work). It is mostly annoying when reviewing package lists everytime I make an update an Pandoc and its dependencies are in it.

                  This kind of issue is precisely why I’d like to investigate something such as Guix, but I haven’t found the time yet.

                  1. 1


              2. 1

                With the new split of pandoc-cli, pandoc-lua, pandoc-server, etc. this might be better. For example, these are HTTP server libraries:


                And pandoc-cli now has an option to build without the lua and server dependencies. I don’t really use either of those functionalities myself.

              3. 1

                Agree with this and will add I really appreciate pandoc’s compatibility. I use pandoc and a makefile to build a static site and it started as maybe 5 lines of make, as I wanted to add additional things it was easy to add in pre- and post-processing steps, do templating, write filters etc. While filters do require learning a bit about pandoc internals, filters are just programs that read from stdin and write to stdout. It generally works out of the box great and can be integrated into unix-y pipelines really well without having to own a build process end-to-end like traditional static site generators or other document building toolchains.

              4. 2

                I use pandoc to convert GitHub style markdown to PDF/EPUB ebooks. The default output is good and there are plenty of customization options too. I didn’t know LaTeX/CSS but stitched a few things together with help from stackexchange sites to customize the output produced. Later came to know there are third-party templates that I could’ve used/started with.

                1. 2

                  Pandoc is one of those tools where I’ve always been happy to invest more time in learning it. I wish there was a “Advanced Pandoc” book out there.

                  Stories with similar links:

                  1. Pandoc 2.0 released via goodger 5 years ago | 29 points | no comments