Before anything else can be done, a PreTeXt project with WeBWorK problems must first have its WeBWorK content extracted and processed into multiple representations, which are then collected into an auxiliary XML file. Using the CLI, this is done with pretext generate webwork (if you want to reference a particular target, add -t [targetname]).
If instead you want to use the pretext/pretext/pretext script, you might need to install the Python requests module. It is not uncommon for your computer to not have requests installed (although it comes with the CLI), so you should check if it is there and install it if need be. You can check if it is installed from the command line with:
python -c "import requests"
And if it isn’t, you can install it with pip, specifically with:
Processing WeBWorK problems is best accomplished if you are using directory management. With a publication file, declare the external and generated directories as describe in Section 5.6. Then use the pretext script to extract PreTeXt content from the WeBWorK server. It will be placed in a webwork subfolder of your generated folder. For example:
In the previous example and those that follow, you should specify paths as needed. For example, the pretext script is typically at ~/pretext/pretext/pretext. And the -p option is specifying a publication file.
If absent, these default to https://webwork-ptx.aimath.org, anonymous, anonymous, anonymous, and anonymous respectively. If you specify a server, you must correctly specify the protocol (http versus https). And it must be version 2.16 or later. Do not include a trailing slash.
We assume you are using managed directories, and have WeBWorK representations file as above. Build the HTML with pretext build TARGET where TARGET is the name of a target that has format="html". You can also use pretext/pretext to build HTML. For example:
There are five publisher file entries which control how a WeBWorK problem is realized within HTML output. These are divided based on where the exercise (or project-like) resides: inline, within a division of exercises, within a reading questions division, within a worksheet, or if it is a project or similar. If the class of problems is declared dynamic, then each problem has a button that readers can click to make the problem interactive. Conversely, if the class of problems is declared static, then the problems render with a static preview.
By default, inline exercises and project-like will be dynamic, under the assumption that these are meant to be worked as a reader works through the material. The others will be static, under the assumption that they will be placed on a WeBWorK server where they will be worked for scores and grades. See Subsection 44.4.5 for the precise syntax for these switches.
If an exercise is subdivided into tasks, then by default they will only be revealed incrementally as the reader answers each one correctly. If you would like to have all tasks revealed from the start, then this option may be elected in the publication file (see Subsection 44.8.7).
We assume you are using managed directories, and have WeBWorK representations file as above. Then build as normal with the CLI. Or you may use pretext/pretext to build a LaTeX PDF. For example:
Subsection38.5.4Creating Files for Uploading to WeBWorK
All of the <webwork> that you have written into your project can be “harvested” in such a way that you could send them to a WeBWorK server for use within WeBWorK. The components you would want are PG files for the exercises, PG macros that you wrote, set defintion files corresponding to the sections (or other chunks) of your project, and header files for those sets. All of this was placed into your project’s generated/webwork/pg folder when you executed pretext -c webwork, so you could find it there and package it all up to send to your WeBWorK server.
This will specify a destination for that folder tree other than within generated/webwork/pg. If you additionally use a -z flag, you will instead get a compressed tarball (.tgz file).
