Jrnl: Windows Support

[wren]

We need to talk about Windows support on this project. We say we support it, but don't treat it equally as Mac or Linux.

I want to remedy this. We should either:

1. Treat Windows as a first-class citizen, or
2. Drop support for it.

I would like to officially support it, but it's going to require a few updates. I'm hoping this issue can serve as a place to gather requirements for what needs to be done to fully support Windows. We can then make some issues and get some work done.

Here's the issues I can think of at the moment (in no particular order):

• Run the tests on Windows - There's currently no way for us to tell if a PR broke anything on Windows without a lot of manual testing. But Travis doesn't properly support a Windows Python environment for testing. Maybe we need a second pipeline for running Windows tests? Maybe move from Travis? Or something else?
• Distribute jrnl on a Windows-based package manager - We distribute on Homebrew, but nothing that focuses on Windows (Pip can be a bit unwieldy on Windows). Maybe Chocolatey would be a good fit for this?

Does anyone have any other things to point out for this?

[micahellison]

This came up in #177 also - there's talk of Cygwin, MinGW, and later WSL, but limiting to those would definitely alienate some if not most potential Windows users.

As far as distribution, I like using Chocolatey, but I think most Windows users that might be interested are just going to want to go find a place where they can download an EXE, which we can handle by attaching the binaries to the releases in GitHub.

That leaves the build pipeline. Apparently Travis "works" with Windows and Python but doesn't necessarily "support" it? I'm not sure if that's acceptable, though. It looks like the main drawback is that it has to install python every time it spins up a VM to build, so all builds take at least a couple minutes. I like Travis otherwise and have no idea what it would be like to have two separate build pipelines. Maybe someone else has opinions or ideas about this?

[MinchinWeb]

Software for Windows is typically distributed as an EXE, typically an installer, but sometimes as a "portable" version. Package managers aren't really a thing on Windows, at least the same way they are on Linux. The closest thing Windows has to an official package manager is the Windows Store. Chocolately seems largely targeted as system administrators, and (at least the free version) doesn't actually host any of the installers, but is rather a collection of Powershell scripts (think bash) that download the official installers off the official sites, and then try to automate the install to not require user input.

Python is a good example of the above: you can download and install Python via an EXE installer off of Python.org, there is an official option to install Python from the Windows Store, or there's an unofficial version on Chocolately that run the Python.org installer under the hood.

jrnl also sits in a weird spot for Windows applications in that is terminal based; most programs on Windows run via a GUI. And so to 110% support Windows, we should be offering a GUI, but that seems like a pretty big jump in project complexity (and I know basically nothing about GUI programming). However, sans GUI, I think that the current option (pip-installable) works well, as the program tends to self-select those that are relatively comfortable with the command line, and thus the steps to install Python and then use pip.

The most common hangup for installing packages from pip on Windows is that Windows doesn't ship with C compiler (or any other, for the matter). This has largely been solved with wheels, which precompile C code, and thus eliminating the need for a C compile on the end user's machine. This was an issue with the former crypto library we were using, but the current (for version 2.0) cryptography ships Windows wheels.

So this is a long way of saying that short of building a GUI, I think the current install-via-pip option remains a good one.

---

For Windows testing, AppVeyor is the option I've most commonly seen deployed. Travis is working to support Windows, but hasn't yet added Python to their officially supported list. That said, I've played with Travis, and if you're content to test against a single version of Python, it's doable. (Single Python version testing is much more reasonable on Windows than Linux, because Windows doesn't have system tools shipping with it, and so there are much less hangups to upgrading.)

[micahellison]

Thanks for the comment, @MinchinWeb. I agree that a GUI-based approache and an official channel like the Windows Store would be the most "Windows-native" approach but also, yes, that's quite a bit of scope to add onto this project.

The more I think about pip vs. choco, the more I realize there doesn't even need to be one or the other. We can advise Windows users to use choco to install python, then pip to install to jrnl. It would be just copy-pasting 1-3 commands (depending on whether they have choco and/or Python installed). We could also use that approach (or similar) as part of our test pipeline so it becomes the "supported" way to run jrnl on Windows.

[maebert]

Throwing some extra options in there:

• Homebrew is available for WSL, so for users that already have homebrew, brew install jrnl will be an option on Windows.
• Even Microsoft's official repo for its Terminal app offers choco support, so I think it's fair to say that they expect this to be the de-facto standard for developers.

More importantly, I fully agree with @wren that we should run tests on windows machines. Adding this to Travis shouldn't be to hard though!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MinchinWeb]

bump (un-stale-ize)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MinchinWeb]

Having added testing for Windows, is this in a good place? Or do we want to different installation option than pip?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[wren]

We now have a separate issue for choco deployment, so I think this ticket is good now that the tests are fully operational and have been running for a couple of months.

[sergeevabc]

Err… Windows 7 user here.
No Chocolatey or other 3rd party managers are used to get and update software.
Plain oldschool downloading of portable binaries (EXE) is (and will be) used instead.
Does Jrnl exist in this form to try?

[MinchinWeb]

@sergeevabc : No EXE yet, but jrnl can be installed in a couple of steps.

1. Download Python. https://www.python.org/downloads/ -- Right now, the current version is 3.8.3, and download the Windows Installer.
2. Install Python. Make sure you select the option to add Python to PATH (I believe it's selected by default).
3. Open a new CMD / PowerShell window and make sure Python is working. Run python --version. You Should get something like "Python 3.8.3".
4. Install jrnl. Run pip install jrnl (pip is used to install Python code like jrnl).
5. Confirm jrnl is installed; run jrnl --version

From here, you can try out jrnl. The configuration file is started at <User Directory>/.config/jrnl.

Let me know if that works.

[wren]

@sergeevabc: MinchinWeb is mostly right, except that we recommend using pipx instead of pip. From our testing, pipx is the easiest way to install on Windows (and other platforms). It takes Python apps, and does a bunch of magic to get them running in a completely isolated environment (much like an exe), so it avoids many of the issues we've run into with pip in the past.