-
Notifications
You must be signed in to change notification settings - Fork 43
Description
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 (windows port #4)? Build a
chocopackage (as it was done for pandoc), or build an MSI or equivalent installer - macOS/Linux (add linux install instructions for linuxbrew #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
pkgpackage.