paleolimbot / rbbt

R Interface to the Better BiBTex Zotero Connector
142 stars 25 forks source link

.bib for testing #9

Open dmi3kno opened 4 years ago

dmi3kno commented 4 years ago

Thanks for excellent package. As I was testing the package on my machine for PR, I came across the key you are testing BBT connection for dunnington_etal18. I created this dummy entry in my Zotero for test to succeed, but you could consider putting .bib file in, for example, data-raw and instruct people to import it to Zotero, for the tests to go through.

@article{dunnington_etal18,
  title={ggspatial: Spatial Data Framework for ggplot2},
  author={Dunnington, Dewey},
  journal={URL: https://cran. r-project. org/package= ggspatial},
  year={2018}
}
paleolimbot commented 4 years ago

Thanks! It's a good point. I'd also like to figure out how to get a zotero instance running on GitHub actions so that all this can be tested automatically, but, a battle for another day (this issue will serve as a good reminder!)

paleolimbot commented 3 years ago

@florisvdh do you have any experience trying to run Zotero headless? I can get Zotero's http server to start but I can't seem to get the betterbibtex endpoint to work:

https://github.com/paleolimbot/rbbt/blob/master/.github/workflows/R-CMD-check.yaml#L93-L95

https://github.com/paleolimbot/rbbt/runs/1287087762?check_suite_focus=true#step:10:36

florisvdh commented 3 years ago

Hi Dewey, no, I'm afraid I haven't. Used Zotero only locally, in Linux.

Also it doesn't seem related to what's mentioned at the top of https://retorque.re/zotero-better-bibtex/citing/cayw/, as the answer 'Request not allowed' when entering http://127.0.0.1:23119/better-bibtex/cayw?probe=TRUE in the browser is not the same as the 404 error you get. So indeed it looks like BBT didn't start, then.

paleolimbot commented 3 years ago

Thanks for looking into this - you were so good at headless QGIS that I thought you might have tried! Eventually I'll give Linux or MacOS a shot.

dmi3kno commented 3 years ago

There are some leads here

bwiernik commented 2 years ago

@retorquere Could you help out with running Zotero in GitHub actions?

retorquere commented 2 years ago

TIMTOWTDI, but for me, the following has worked consistently. Basically I just start Zotero under xvfb on Linux (because GHAs don't have a screen).

I have only ever tested this on MacOS and Linux; I have at some point tested it on Windows under WSL, and WSL has improved since I heard so it should still work, but I haven't touched this in a long while. Long story short, I can really only help you for linux and macos.

To run automated tests, the following points need to be taken care of:

  1. you must have a way to get past the first-run behavior of Zotero
  2. you must have a way to install plugins if those are part of your tests
  3. you must have a way to drive Zotero

For the first point I have just started Zotero on my desktop, let it create a profile and do its first-run stuff, and use that as a base (mine is checked in here). As far as I can tell, profiles are cross-platform, although the profiles.ini has platform-dependent paths. I have a setup that is safe to run on my own desktop but that has gotten pretty complex; it uses selenium to handle installs, and a monkey-patched behave to drive the tests. A simpler setup is to just create ~/.zotero/zotero/profiles.ini:

mkdir -p $HOME/.zotero/zotero

cat << EOF > $HOME/.zotero/zotero/profiles.ini
[General]
StartWithLastProfile=0

[Profile0]
Name=Default
IsRelative=0
Path=$HOME/Zotero
Default=None
EOF

If you then dump the prepared profile into ~/Zotero, that will let you start Zotero using

zotero -purgecaches -P Default -ZoteroDebugText -datadir profile > $HOME/zotero.log &

The benefit of running with -datadir profile is that you know where the zotero-own files end up.

In order to install plugins I use selenium, but that is overkill in retrospect, as you can just point Zotero to the unpacked plugin; you could use something like this to set that up. Easy to do for multiple plugins too. That would take care of point 2.

For point 3, I'd recommend just installing debug bridge. As part of the startup script for point 2 you'd have to set a password, but that's just an extra line in the prefs.js file.

Now you can send snippets of JS to Zotero to execute, and thus drive your tests. I use behave for this, but you don't need all of that; essentially, this is the bridge between the python code driving the tests and Zotero.

I think for Zotero's own test suite they load a javascript test framework (mocha IIRC) into Zotero (maybe through a plugin, or maybe they do special test builds, I don't know) and run all of the tests inside Zotero. I found my easier and it would test with a production Zotero, which has my preference. But the basic setup with xvfb and creating the profile should be the same if you want to go the mocha way. Can't help with that though.

As for installing Zotero into GHA, getting the tarball should work fine, but I install from https://github.com/retorquere/zotero-deb; I created that originally for my tests, but it turned out to have broader appeal.

paleolimbot commented 2 years ago

Thank you for the update here! I'm not in a good place to implement this on GHA in the near future but would be happy to review any PR that does!