Local pg files

[Alex-Jordan]

This lets you have local PG files (somewhere within your "external" directory tree). This is the next "big" WeBWorK feature from the Tacoma work.

Additionally (meaning beyond the Tacoma work) I now have this feature working for versions of WeBWorK prior to 2.19. So this doesn't need to wait until the various WW servers are upgraded. If you test this as-is (for both the minimal and sample chapter examples), it will use the AIM server, currently at 2.17. Then if you'd like to test on a 2.19 server, switch the publisher file (for either of the two examples) to use "pretext-dev.aimath,org".

While doing this work I came across two minor things that should have been cleaner in other relatively recent PRs. They are tacked on to separate commits here. If a separate PR is best, no problem. My testing had these in place before I realized they should be separated, so including them for now.

[rbeezer]

The feature here is a local copy, the attribute is @local. Then the code switches to tracking this scenario with the moniker "external". I know the files live in the "external" directory, but I think this will confusing with all the frequent uses of "external".

Looks like your internal use of "external" could be cosmetically switched to "local"?

Given the volume of PRs, I cannot keep track of dependencies. I already started on "custom names" which will impact this, or the other way around. I should have started with #2612 and then this should have built on it. But it is too late.

Let's finish this one: #2620. Mark #2612 as a draft, and then tidy it up after this is merged and I will start over on that one.

[Alex-Jordan]

#2612 is now draft.

Before I change "external" to "local", I want to check in. There is already "local" for PG processing. As in, rendering for static PTX by using your local copy of the pg repository. Now here in #2620 there will be local PG files too. I was using "external" in the pretext.py file to help me quickly get to chunks of code that touche on this feature versus that one.

• Search for local if I want to get to something having to do with local PG processing.
• Search for external if I want to get to something having to do with processing a local .pg file.

So yes, I can change it. And I will if you still think it's best. But what may seem to make it less confusing for some, may make it more confusing to keep the two meanings of "local" separate.

Is there a third way?

[Alex-Jordan]

Also, please clarify:

• if I should actually change "external" to "local", or if you were just musing.
• and if I should make a change like that, if I should add on a commit or recombine and do a force push.
• and if I should add a commit, if the format of the commit message will ultimately be irrelevant

[rbeezer]

Some ideas as I think more about this, which makes some of the questions just above moot, or at least delayed.

These "local" problems are part of an author's source, and are text. They should go into the source, not off in separate files (like a raster image needs to go). So make the PG-authored problems the content of a webwork and we can add a @syntax="pretext|pgml" to tell the difference (if necessary). Then extract-pg.xsl can just rip them out verbatim (maybe a sanitize-text to shift them left) and then everyting happens as if our XSL had produced PG.

If having them live in files of their own is an important convenience, then xi:include can be used for that.

We are having a very similar discussion over on #2615. And maybe this will be relevant for STACK problems too.

[Alex-Jordan]

I feel that .pg files should be treated as external assets. This is a big decision, and does this need to move to -dev? Alex Jordan Mathematics Instructor Portland Community College

…

On Mon, Jul 21, 2025, 6:25 PM Rob Beezer ***@***.***> wrote: *rbeezer* left a comment (PreTeXtBook/pretext#2620) <https://urldefense.com/v3/__https://github.com/PreTeXtBook/pretext/pull/2620*issuecomment-3100259862__;Iw!!Ka_JY85zDv0FFw!kCedby1t1G-URTUVYHCGIEGxcp0dHZzs-L-q5bKphkQS3C-6zpdZDiqckRCPZQLt1cCk8Ak1buh4UkQlYDTRCopNGMg$> Some ideas as I think more about this, which makes some of the questions just above moot, or at least delayed. These "local" problems are part of an author's source, and are text. They should go into the source, not off in separate files (like a raster image needs to go). So make the PG-authored problems the content of a webwork and we can add a @syntax="pretext|pgml" to tell the difference (if necessary). Then extract-pg.xsl can just rip them out verbatim (maybe a sanitize-text to shift them left) and then everyting happens as if our XSL had produced PG. If having them live in files of their own is an important convenience, then xi:include can be used for that. We are having a very similar discussion over on #2615 <https://urldefense.com/v3/__https://github.com/PreTeXtBook/pretext/pull/2615__;!!Ka_JY85zDv0FFw!kCedby1t1G-URTUVYHCGIEGxcp0dHZzs-L-q5bKphkQS3C-6zpdZDiqckRCPZQLt1cCk8Ak1buh4UkQlYDTRMXU6hng$>. And maybe this will be relevant for STACK problems too. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/PreTeXtBook/pretext/pull/2620*issuecomment-3100259862__;Iw!!Ka_JY85zDv0FFw!kCedby1t1G-URTUVYHCGIEGxcp0dHZzs-L-q5bKphkQS3C-6zpdZDiqckRCPZQLt1cCk8Ak1buh4UkQlYDTRCopNGMg$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABEDOAFACJ3MWYDBJT5X6CT3JWHHBAVCNFSM6AAAAACB6PWF3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMBQGI2TSOBWGI__;!!Ka_JY85zDv0FFw!kCedby1t1G-URTUVYHCGIEGxcp0dHZzs-L-q5bKphkQS3C-6zpdZDiqckRCPZQLt1cCk8Ak1buh4UkQlYDTRKGT799Q$> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rbeezer]

does this need to move to -dev?

Discussions of PreTeXt markup are always welcome on -dev. Encouraged, even.

[Alex-Jordan]

OK, I drafted something for -dev. Before I send, maybe it's possible the issues I see will persuade you and I don't need to post. So for your consideration, here are the cons that I see with what you suggested:

• Not treating the .pg files as external assets. They will usually be developed somewhere else, then brought into the PTX project. To me that is the core of what an "external asset" is. This feature is for authors who use WeBWorK in PTX but do not know how to code in PG, and do not have control over a course in a webwork2 server. These PTX authors are using .pg problem files they get from somewhere else but cannot put into a host course.
• Perl occasionally cares about the first character on a line. With PG, it cares a lot, because things like "END_TEXT" and "END_PGML" need to be at the start of a line. These proposed methods would have to use the sanitize-text device that shifts a block of text to the left, and the author will need to fully understand how their indented source will be shifted left, and make sure certain bits end up aligned on the first column.
• Using xi:include, the paths to these files are relative to the file you are working in. I'd rather work with consistently using the managed external folder as a root.
• The added verbosity for anyone who is actually using local PG files.
• A .pg file might have its own external assets that it depends on. Image files, data files, and other pg files are the examples I know of. This can all work out if those assets are kept near the .pg files, and within the .pg file it references those assets using relative file paths to the .pg file. I don't know how this will all work out if the .pg file is treated as source (that is processed by XSLT as text) and those assets are still external assets.

Let me know if this sways you. Or if not, I can open a discussion.

[rbeezer]

I can open a discussion.

I think that would be best.

[Alex-Jordan]

Closing this for #2631.