Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package update requires manual replacement of pinp.bst #82

Open
ikashnitsky opened this issue Mar 5, 2020 · 4 comments
Open

package update requires manual replacement of pinp.bst #82

ikashnitsky opened this issue Mar 5, 2020 · 4 comments

Comments

@ikashnitsky
Copy link
Contributor

This is a small nasty thing that mage me kill several hours twice (with a gap of maybe half a year). Once the package is updated, a fresh cope of pinp.bst is required, and the directory with previously knitted document hold an outdated copy. Maybe there is a way to give an informative message in such a case?

@eddelbuettel
Copy link
Owner

Howdy (and nice meeting you last weekend ;-)

I think that has bit me too once before.

Question is ... how to best compare? Just two file.info() calls and compare size? I'd rather not depend on digest to compare checksums. Does R has a base checksummer? Or should we just always copy it out?

@coatless
Copy link
Collaborator

coatless commented Mar 5, 2020

The issue here is some may modify the pinp.cls file. So, copying on every knit probably isn't ideal.

Probably, best to check file.info() and emit a message that emphasizes the underlying class file changed. If the compilation is broken, then delete the old .cls file for a new one to be added in its place.

The pinp.cls file is not in-sync with the package.
This may happen if it has been modified either locally or during a package update.
If there is trouble knitting the document, please delete the pinp.cls file.

@eddelbuettel
Copy link
Owner

So, copying on every knit probably isn't ideal.

Yep. There was a reason we didn't do that.

But then suppose someone mod'ed it for good reason. Should we then yell at them each time we render the document because we see a change?

A puzzle...

@eddelbuettel
Copy link
Owner

There is tools::md5sum. So maybe we just 'quickly' run that over both, and issue the warning if different. If we feel generous we can add package-environment toggle to tell it to never yell....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants