PreTeXtBook / pretext

PreTeXt: an authoring and publishing system for scholarly documents
https://pretextbook.org
Other
266 stars 208 forks source link

mathbook commit hash in output #559

Open Alex-Jordan opened 7 years ago

Alex-Jordan commented 7 years ago

See if there is a way to print the commit hash that mathbook is on into a comment in output files. Would help for identifying issues with old output.

rbeezer commented 7 years ago

That's a good idea. But XSL can't "call" othr programs, so I don't have any good ideas about how to accomplish this. But maybe it will come to me.

For the record, this approach might be a start, though the XSL won't know where the file is...

http://stackoverflow.com/questions/16364826/git-have-current-commit-hash-and-latest-tag-in-file-on-commit

On 05/02/2017 08:29 PM, Alex Jordan wrote:

See if there is a way to print the commit hash that mathbook is on into a comment in output files. Would help for identifying issues with old output.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/559, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2coy9wvpJ81BSgow0aBzE4FaupDtAks5r1_SvgaJpZM4NO7O5.

Alex-Jordan commented 7 years ago

If I do:

cat ~/mathbook/.git/HEAD

I see:

ref: refs/heads/dev

Based on this, if I do

cat ~/mathbook/.git/refs/heads/dev 

I see

8de5f7951a099ced0a76a505974d8f4546a8037b

For now let's assume that this all behaves all the time like it appears to behave: a way to identify your branch and the commit hash that branch is at as the contents of certain files in the .git folder.

I know XSL can't execute other programs, but I believe it can insert text from other files. So then the next question is, how would you apply xsltproc to a project file like say ~/orcca/src/orcca.mbx and the XSL knows to look in totally different places like <path-to>/mathbook/.git?

rbeezer commented 7 years ago

Right.

Two hurdles:

(a) "totally different place" as you suggest.

(b) if XSL looks for a file and it does not exist, it is a fatal error. No conditioning on existence.

(c) Who runs the "cat"?

Yes, that is three. Easily scriptable, but who among us will add the right incantations to our scripts?

I guess we could make a default file that says there was no scripting and suggests a remedy? But that sort of defeats the purpose.

On 05/02/2017 09:56 PM, Alex Jordan wrote:

If I do:

|cat ~/mathbook/.git/HEAD |

I see:

|ref: refs/heads/dev |

Based on this, if I do

|cat ~/mathbook/.git/refs/heads/dev |

I see

|8de5f7951a099ced0a76a505974d8f4546a8037b |

For now let's assume that this all behaves all the time like it appears to behave: a way to identify your branch and the commit hash that branch is at as the contents of certain files in the |.git| folder.

I know XSL can't execute other programs, but I believe it can insert text from other files. So then the next question is, how would you apply xsltproc to a project file like say |~/orcca/src/orcca.mbx| and the XSL knows to look in totally different places like |/mathbook/.git|?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/559#issuecomment-298823243, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2ckXcCBK8wzJsvqwqp_BYOb5dgxLBks5r2AkIgaJpZM4NO7O5.

Alex-Jordan commented 7 years ago

(a) I was thinking maybe xsltproc can also reference the file path to the xsl file it is using in addition to the xml file it is acting on. (wild speculation, and moot given (c) below)

(b) .../.git/HEAD should always exist, and if you append the tail end of its contents to .../.git/ then that file should exist too.

(c) No one runs cat. I just put that there as an easy way for you to verify what the contents of these files are. But I've been reading up, and inserting text from text files is not possible without a root element in the text file (when using XSLT 1.0). So this idea --- using git's own internal record-keeping files --- falls apart.

rbeezer commented 7 years ago

This is a great idea, but I can't see a way to make it fool-proof automatic. We might be able to use a git hook and script something, but people building with scripts won't need as much help.

The build date is in each file, which I know is not as good. Right now I can't see this as a priority.

Manually putting the MBX hash in docinfo is one option. Definitely should support document source hash in docinfo to migrate to front colophon. Maybe do that already.

On May 2, 2017 10:21:58 PM PDT, Alex Jordan notifications@github.com wrote:

(a) I was thinking maybe xsltproc can also reference the file path to the xsl file it is using in addition to the xml file it is acting on. (wild speculation, and moot given (c) below)

(b) .../.git/HEAD should always exist, and if you append the tail end of its contents to .../.git/ then that file should exist too.

(c) No one runs cat. I just put that there as an easy way for you to verify what the contents of these files are. But I've been reading up, and inserting text from text files is not possible without a root element in the text file (when using XSLT 1.0). So this idea --- using git's own internal record-keeping files --- falls apart.

Alex-Jordan commented 7 years ago

No priority for sure. Just jotting down thoughts as I have them for future reference.

Maybe obvious to others, but I just came to realize a git hook is local to your repo. It's not something you can push and have others acquire when they pull. A bit of a nail in the coffin.

If there is a future where you compile output using the mbx script or even a GUI (that relies on the mbx script), then that would be a good time to implement this. Because the mbx script could easily do it at the same time (either immediately before or immediately after) it runs xsltproc.

rbeezer commented 7 years ago

YES! Definitely with a pretty front-end we should manufacture and incorporate these sort of details.

On May 3, 2017 11:18:18 AM PDT, Alex Jordan notifications@github.com wrote:

No priority for sure. Just jotting down thoughts as I have them for future reference.

Maybe obvious to others, but I just came to realize a git hook is local to your repo. It's not something you can push and have others acquire when they pull. A bit of a nail in the coffin.

If there is a future where you compile output using the mbx script or even a GUI (that relies on the mbx script), then that would be a good time to implement this. Because the mbx script could easily do it at the same time (either immediately before or immediately after) it runs xsltproc.