Having um in multiple platforms

[iajrz]

Since this went into hacker news a few weeks back I've been watching the project. I think it would be beneficial to set a direction for the project, so as not to acquire any unwanted responsibilities and make sure the project stays lean and matching its purpose.

There are a few things going on at the same time, mostly trying to get um to be multiplatform, namely enabling it to run on Linux, Windows and FreeBSD. This has been somewhat conflated with making it "not rely on pandoc" (see #10, #6, #4 and #13).

I think this is a mistake, and perhaps you'll agree and we can restructure the issues and organize the efforts to increase um's availability without squandering man-hours. It's possible I'm mistaken - I welcome the learning opportunity.

um is written in Ruby, which can run on all the desired platforms. Except it depends on pandoc. But this is not really a hurdle since pandoc is distributed in all desired platforms.

The availability requests are actually packaging requests for the most part, not really requiring the project to change. um shouldn't have the burden of managing its dependencies. That's what package managers are for.

Packages are projects unto themselves, and need not be conflated with the main project. A good direction to multi-platform availability of um is #16.

I think if anyone wants to make this project available to other platforms, they should do so by packaging it, and packages are separate projects. These are examples of what could be done:

• Windows (#4)? Build a choco package (as it was done for pandoc), or build an MSI or equivalent installer
• macOS/Linux (#16) can be kept by maintaining the Homebrew package up to date, can be enhanced by building packages for the different distros.
• FreeBSD can be managed by making a pkg package.

[sinclairtarget]

Just a note—as of 4.0.0, Pandoc is no longer a dependency. The Kramdown gem is instead. As @iajrz pointed out, this wasn't necessary in order to make um available on other platforms. But hopefully it makes it marginally easier given that Pandoc was a pretty heavy dependency.

Leaving the issue open in the hope that somebody who knows more about these other platforms will be able to do the packaging work required.

[sinclairtarget]

Also FYI, see UPGRADE.md for more information about the switch to Kramdown, which is a breaking change if you've made much use of Pandoc's Markdown extensions (which the default .md um page template does).

[He-Ro]

I agree with @iajrz that most of the issues about ports should not burden um as a project. Ideally for each distribution there should be someone packaging um according to how the distribution expects packages to be.

With the change to a Gem this has gotten tremendously easier! Since for most distributions there already exist other projects that are gems, thus each packager can take clues from those packages (or there even exist official guidelines how to package a Gem).

I have recently created a package for Arch Linux in the User Repository AUR: https://aur.archlinux.org/packages/um-git/ Since um is a Gem the package is a quite clean. Note that for the package kramdown is not installed by the Ruby Gem, but with the package manager of Arch Linux. This is one of the examples where the package deviates from the official version, because this is the way how to package on Arch. One should rely on the Arch package manager for dependency resolution.

If you want, you can add a link to the AUR package to the README for fellow Arch users. Maybe in the future more people will package um and you can add those to the README as well.

[sinclairtarget]

@He-Ro If you'd like to add info about how to install your package on Arch, feel free to make a PR changing the README.

Thanks for your hard work!

[sinclairtarget]

Going to leave this issue open for now in case anyone comes along feeling inspired to package um for more platforms. As @iajrz pointed out, um isn't yet available for Windows as a choco package or for FreeBSD as a pkg package.