Ensure Windows support/documentation

[StevenClontz]

While a goal of this project was to support Windows by getting things working purely Python-land, I'm not sure if this is a worthwhile goal. Since there's an Ubuntu app in the Windows Store that uses WSL, I'm wondering if we should focus on that workflow for Windows users.

[daverosoff]

What do you mean? What are you considering abandoning?

[StevenClontz]

Not so much "abandon" as "not attempt to support". pretext build --diagrams relies on non-Python dependencies, which we have yet to document for users of pretext-cli (for any OS), and I don't think anyone (@oscarlevin ?) has successfully used pretext build --diagrams on Windows. I think it's possible that getting the Ubuntu app running + apt install [the_things] is no more painful than getting things installed natively in Windows, in which case I'd rather not have to maintain separate support for WIndows users. So unless someone else wants to adopt Windows support for this project, that's the direction I'm leaning.

[oscarlevin]

We should be careful here. It is true that I have had some trouble building latex-images on Windows (I had to install the pdf2svg thing, and pdfcrop still isn't working for me). Those things might work a lot better using WSL (they work, for one thing). But there are at least two good reasons to support windows without WSL:

1. We want text editors to be able to call pretext build. Even before then, reminding users to always first type bash in their terminal before they can run pretext build is messy (I do this for my current makefiles, and always forget, which is annoying).
2. Eventually we want to allow calling pdflatex or xelatex. I don't want to require users to have a texlive install both on Windows and in WSL; and anyway, the texlive in WSL is out of date and gives me errors when I try to use it. There is a way to call the windows version of pdflatex from within a WSL bash shell, but the command is more complicated. Perhaps we could guess at it, but this seems messy.
3. Okay, more than two issues: not all Windows users have an easy way to get WSL or Ubuntu from the windows store (it looks like you need to turn on WSL before getting Ubuntu). WSL is only supported on more recent builds of Windows 10, and requires turning features on. So the dream of having this install from inside VSCode or similar would die.

[sean-fitzpatrick]

@oscarlevin I gave up on using Windows because I couldn't find a way to get a working pdfcrop. (And I mean gave up to the extent of dropping almost $2K on a Dell that shipped with Ubuntu.) If you find a way to make it work, I'd be interested. (Not in going back to Windows. But in knowing what the solution was.)

[StevenClontz]

Leaving this here: https://code.visualstudio.com/docs/remote/wsl

[sean-fitzpatrick]

Interesting. I tried using WSL awhile ago but struggled because I could run command in my Ubuntu terminal, and those commands would produce some files, but I never figured out how to access those files from Windows file manager. (I think I once resorted to sftp from WSL into another server, and then FileZilla to get them onto Windows...)

I should look at VSCode again. I installed it once and went back to Atom after 10 minutes. There were all sorts of things going on that weren't the code is wanted to edit. (It took me 5 minutes the first time I used atom to figure out how to install the PreTeXt package. I never did figure out how to do it in VSCode!)

[StevenClontz]

pretext view gets your built files in the browser for quick access.

I believe WSL exposes your Windows file system via e.g. /mnt/c/

[daverosoff]

@StevenClontz last comment brings up exactly the thing that makes me side more with @oscarlevin here. That is true, but it depends on having the right version of Windows 10. I still don't have it, because my install is controlled by my college's IT (who are great). Of course, I also want to be able to use these tools in PreTeXtual. That's a real, tangible thing—it's a Sublime plugin, so it's written in Python. It and Oscar's Atom plugin have been huge in getting new users into PTX. This success relies on getting the PTX tools working natively in Windows.

[StevenClontz]

Then the question seems not to be "if" we will support Windows natively, but "how". In particular, if a feature isn't yet implemented on Windows, we should be explicit about this.

This is related to #50 -- we need to document installation of all external applications that our CLI will attempt to use. If we haven't figured out how to get something working on Windows yet, then we need to add a NotImplementedError (or whatever that is in Python) and make sure it's clear in pretext --help that Windows users cannot use those features.

[StevenClontz]

(I'm currently setting things up natively on my Windows machine, and it's making me think what we really want is a PreTeXt-CLI binary for Windows; something a user can download, double-click, and get everything installed and on their PATH in one go. Maybe https://pyinstaller.readthedocs.io/en/stable/ ?

[sean-fitzpatrick]

I was doing PreTeXt on a Surface Pro for awhile. Everything worked except for PDFcrop. Installing it is a mess because you need to first set up a Perl installation for Windows, if I recall correctly, and at the end it doesn't even work. (It works in the sense that the pretext/pretext script can call it, and it claims to execute something, so the script doesn't fail. But it doesn't actually crop images.)

My workflow was to edit in Atom (I found that Oscar's plugin worked a bit better than Dave's Sublime plugin, because Atom does snippets better. Or maybe I never learned how to use them in Sublime. But I'd still open in Sublime every now and then because it has a plugin (Emmet?) that tells me when I made a stupid typo and broke my XML) and then build in Git Bash.

Git Bash is easier than Anaconda because (a) you can define functions in your .bashrc, and (b) you can use relative paths, with UNIX syntax. I found that I always had to use full Windows paths in Anaconda, which is annoying as hell. (And Git Bash has persistent bash history. Anaconda forgets your previously entered commands as soon as you exit.)

[sean-fitzpatrick]

But way awesomer would be if those functions were defined not in my Git Bash .bashrc, but in a plugin for Sublime/Atom/VSCode, and I just had to select the appropriate build command from a menu (or button! Windows users like shiny buttons!)

A year ago in Portland I think @daverosoff was working on a Windows installer that would pull in all the dependencies.

One step to get things working on Windows has to be finding an adequate replacement for pdfcrop on Windows. Question for @rbeezer : when we process <latex-image>/tikz using pretext/pretext, is there a compelling reason to generate the .tex file as we do? Right now, each image gets extracted to a document like so:

\documentclass[options I can't recall]{article}
<<all the latex-preamble>>
<<all the latex-image-preamble>>
\begin{document}
contents of <latex-image>
\end{document}

Does anything break if we don't use the article document class? What if the .tex file began with \documentclass[tikz,crop]{standalone}?

This is what I use for testing TikZ code in my PreTeXt documents (when I don't want to do a whole PreTeXt build to see one image) and the cropping generally comes out how I expect.

[StevenClontz]

Another link I'll drop on bundling a Python Click CLI with PyInstaller: https://stackoverflow.com/a/45338240/1607849

[StevenClontz]

Does anything break if we don't use the article document class? What if the .tex file began with \documentclass[tikz,crop]{standalone}?

+1

If that's all pdfcrop is doing, then having LaTeX do the cropping in the first place sounds like a slick way to get rid of an obnoxious external dependency.

[rbeezer]

I don't recall "article" being a necessity. Just a minimal LaTeX class. We'd want to test the "crop" option carefully.

On 7/3/20 9:27 AM, Steven Clontz wrote:

Does anything break if we don't use the article document class? What if the
.tex file began with \documentclass[tikz,crop]{standalone}?

+1

If that's all pdfcrop is doing, then having LaTeX do the cropping in the first place sounds like a slick way to get rid of an obnoxious external dependency.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PreTeXtBook/pretext-cli/issues/48#issuecomment-653615346, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOLM4VPPXGK6ER3AAVFDHTRZYBHBANCNFSM4OOMRJWA.

[sean-fitzpatrick]

How about if I make this change on my local copy of the pretext/pretext script (and extract-latex-image.xsl) and then run it on APEX? That provides 768 TikZ images as test cases :-)

[StevenClontz]

The tikz crop solution would be an upstream enhancement in rbeezer/mathbook so I made an issue for it: https://github.com/rbeezer/mathbook/issues/1327

[sean-fitzpatrick]

I was about to indicate the changes I'd make but I'll do so on #1327

[rbeezer]

Yes, an APEX test would be good - I'll keep an eye on https://github.com/rbeezer/mathbook/issues/1327

On 7/3/20 9:45 AM, Sean Fitzpatrick wrote:

I was about to indicate the changes I'd make but I'll do so on #1327

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PreTeXtBook/pretext-cli/issues/48#issuecomment-653620175, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOLM4WNO6W4IAXLHNQKZXTRZYDL7ANCNFSM4OOMRJWA.

[daverosoff]

(I'm currently setting things up natively on my Windows machine, and it's making me think what we really want is a PreTeXt-CLI binary for Windows; something a user can download, double-click, and get everything installed and on their PATH in one go. Maybe https://pyinstaller.readthedocs.io/en/stable/ ?

I have been dreaming about IronPython for this. PyInstaller is another idea.

[StevenClontz]

Looks like Iron Python doesn't support 3.x yet, so that's a blocker.

On Sun, Jul 5, 2020, 12:28 PM Dave Rosoff notifications@github.com wrote:

(I'm currently setting things up natively on my Windows machine, and it's making me think what we really want is a PreTeXt-CLI binary for Windows; something a user can download, double-click, and get everything installed and on their PATH in one go. Maybe https://pyinstaller.readthedocs.io/en/stable/ ?

I have been dreaming about IronPython for this. PyInstaller is another idea.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PreTeXtBook/pretext-cli/issues/48#issuecomment-653915778, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL4YUDJDWILFOSEPZISI2DR2CZ4FANCNFSM4OOMRJWA .

[daverosoff]

@sean-fitzpatrick

Git Bash is easier than Anaconda because (a) you can define functions in your .bashrc, and (b) you can use relative paths, with UNIX syntax. I found that I always had to use full Windows paths in Anaconda, which is annoying as hell. (And Git Bash has persistent bash history. Anaconda forgets your previously entered commands as soon as you exit.)

The intent of how I wrote the original Windows install routine was to use the python provided by Anaconda from the Git Bash command line. Is that not what you're doing? I never use any of the actual Anaconda GUI stuff. It could be there's a better solution than Anaconda available now.

[sean-fitzpatrick]

@daverosoff That's how I used to do things. But one of the changes that took place during the move from script/mbx to pretext/pretext is that Python 3 is now required (fine) but the "shebang" at the top (#!/usr/bin/env python3) doesn't play nice with Git Bash. I spent a day trying to figure out how to reconfigure Git Bash to accept that line. (There are various Stack Overflow pages related but I didn't find a solution.) Probably I should just remove the line, but then I'd have to do this every time I update PreTeXt.

[oscarlevin]

I think we are okay now.

[sean-fitzpatrick]

Oh, geez I forgot all about this issue or I might have said something when I added documentation, lol. @daverosoff I have unceremoniously removed the line in your Windows documentation saying that it's he best way to set up PreTeXt on Windows.

Installing pdf2svg might still be annoying for a Windows user who is bad at computers, but other than that, the only remaining difficulty is pageres.

I took a look at the Pyppeteer documentation and it seems like it should be possible to write it into the script instead of calling the pageres executable, but it's not a drop-in replacement: some of the parameters go in different places, and I wasn't sure I understood how to incorporate the delay parameter.

[daverosoff]

That is great, @sean-fitzpatrick, I would never advise a new Windows user to do anything but WSL + the CLI at this point. This year I have had to pretty much bail on PreTeXt and am way behind all new developments. :(

[sean-fitzpatrick]

Thinking back to when you helped me get things set up on a Windows computer in Austin, and it took like a day and a half, we've come a long way. No need for WSL on Windows, either.

In about an hour (it took me 40 minutes while recording a screencast), we can:

• download, install, and configure VSCode, Python, Git for Windows, MikTex, and pdf2svg
• pip install pretextbook, and install pretext-tools in VSCode
• set up SSH for Windows+GitHub
• create and build your first book
• deploy the html to GitHub

[daverosoff]

My concern was always maintaining Python on Windows. How are we recommending people get Python?

[sean-fitzpatrick]

I recommended using the Windows installer from python.org.

You get Python without all the extra baggage that comes with Anaconda, and there's an option to add it to the Windows PATH while installing. Takes about 30 seconds, and you can immediately find Python from Git Bash.