install rbeezer/mathbook/pretext/pretext.py as "binary" when pretext new, and use as subprocess

[StevenClontz]

In 5aab8a9ec3ae916bed0e81050b4c29dadc7db8a4 I created a script that will automatically pull XSL and pretext/pretext.py from rbeezer/mathbook and put them where we need them (pretext/static/xsl and pretext/core.py). In c890dda61744fbca0893b0d265e605adfe3db31d I updated our repo.

Right now we're not using the core Python at all, because it seems that (it seems to me at least) more global state was added to the pretext/pretext.py script since we integrated it last time, making it incredibly difficult to import directly. I've written a sloppy port to generate diagrams, but temporarily disabled webwork for now. I think the most efficient solution for everyone is to refactor pretext/pretext.py to be more Pythonic by dropping global state, but I'll need to spend some time studying how global state is being used. @rbeezer can we chat later today? https://github.com/rbeezer/mathbook/issues/1487

[oscarlevin]

I like the update script idea, but why are we trying to cleverly import some of pretext/pretext (the python script) into our pretext/core.py. Previously we had duplicated the mathbook/pretext folder in our static folder (adjacent to the xsl folder). We could still have a pretext/core.py file that just has wrappers for calls to that static/pretext, but this would also allow for a developer to use a separate static pull from mathbook elsewhere (passing the location of the whole mathbook repo as an option, instead of our clone in static).

[oscarlevin]

I threw together a possible implementation of the idea in the previous comment at 8d1612b. We can discuss Wednesday and make a final decision. Some old code still commented out instead of removed for now.

[StevenClontz]

Yeah the main bugginess in copying mathbook/pretext/pretext.py into pretext-cli/pretext/core.py is the magic it attempts to do to decide where xsl files are located, which is hard coded using globals hidden behind unconfigurable get/set methods so we cannot tell it that we know better. You did the smart thing for now (which you figured out a year ago): stick it static with the same relative directory structure and the magic will probably work for most people depending on their implementation of pip. We'll discuss further tomorrow.

[oscarlevin]

At the workshop we decided that installing pretext.py in the project directory is not a reasonable approach and not necessary with the new modularization in pretext.py. To handle a freeze of the code, we could use a virtual environment with a specific pretextbook version specified.