Whedon is a collection of command-line utilities to manage JOSS submissions. Whedon is used by the Whedon-API bot to interact with authors and reviewers during the review process on https://github.com/openjournals/joss-reviews
Whedon uses dotenv
to manage local configuration. Take a look at .env-example
(which needs renaming to .env
to be picked up).
Whedon requires a local installation of Pandoc 2 and Pandoc-Citeproc as well as a LaTeX (ideally TeXLive) installation. See Pandoc's install instruction for details.
Hopefully...
Depending on how Ruby is installed on your system there might slightly different steps be necessary. Note that Whedon is only tested for reasonably modern versions of Ruby (i.e. > 2.1) Bundler is used to install dependencies.
On macOS and with a Homebrew installed Ruby Bundler should be installable with
gem install bundler
On other Linux distros this might be a separate package or already installed.
After cloning the whedon
repository with
git clone https://github.com/openjournals/whedon.git
from within the whedon
directory run the following command:
bundle install
or
bundle install --path vendor/bundle
Next, it's necessary to create a .env
file based on the example
.env.test
.
The GH_TOKEN
can be created following the instructions from GitHub's
help pages.
Once you have edited the .env
file you can run the commands described below.
It might be necessary to prefix the whedon
command with bundle exec
or
give the full path to the executable, e.g. ./bin/whedon
.
There are two main ways to use Whedon
, 1) via the command-line utility or 2) using the Ruby API. If you want to see how the command line is implemented, take a look at the executable.
List available commands:
$ bundle exec whedon # or just 'whedon' depending on whether you have built and installed the RubyGem locally
Commands:
whedon compile # Compile the paper and XML metadata
whedon deposit # Deposit the metadata with the JOSS application and Crossref
whedon download # Download the repo
whedon help [COMMAND] # Describe available commands or one specific command
whedon open # Open browser for review
whedon prepare # Just prepare the PDF
whedon reviews # Lists open reviews
whedon verify # Check the key values in the review issue
whedon reviews
List all open reviews in the GitHub review repository:
$ whedon reviews
# Ruby API equivalent
>> require 'whedon'
>> Whedon::Paper.list
whedon verify
Verify the review issue body has key fields present:
$ whedon verify {id}
# Ruby API equivalent
>> require 'whedon'
>> Whedon::Paper.new(issue_id).audit
whedon open
Open the browser at the review issue page
$ whedon open {id}
whedon download
Download locally the repository linked to in the review issue (note this tries to do a simple git clone
of the repository address which will fail for non-git repositories).
$ whedon download {id}
# Ruby API equivalent
>> require 'whedon'
>> Whedon::Paper.new(issue_id).download
whedon prepare
Compile a downloaded paper locally to a PDF.
This is the command that the Whedon-API
bot uses to generate a preview of the paper PDF for sharing with reviewers and editors.
$ whedon prepare {id}
# Ruby API equivalent
>> require 'whedon'
>> review = Whedon::Review.new(issue_id)
>> processor = Whedon::Processor.new(issue_id, review.issue_body)
>> processor.set_paper(path_to_paper.md_file)
>> processor.generate_pdf
Under the hood, the prepare
method does the following:
- Looks for the paper.md
- If more than one paper.md is found, asks the user to pick the correct one
- Compiles the markdown to a custom PDF:
pandoc -o paper.pdf -V geometry:margin=1in --filter pandoc-citeproc paper.md --template latex.template
. See the actual command here. - Returns the filesystem location of the compiled PDF for inspection
whedon compile
$ whedon compile {id}
# Ruby API equivalent
>> require 'whedon'
>> review = Whedon::Review.new(issue_id)
>> processor = Whedon::Processor.new(issue_id, review.issue_body)
>> processor.set_paper(path_to_paper.md_file)
>> processor.compile
Under the hood, the compile
method does the following:
- Looks for the paper.md
- If more than one paper.md is found, asks the user to pick the correct one
- Compiles the markdown to four different outputs:
- The JOSS PDF
- A (currently un-used) custom XML output
- An HTML representation of the paper (deprecated)
- The Crossref deposit metadata
- Returns the filesystem location of the compiled PDF for inspection
Accept a paper into JOSS. This method currently returns the necessary metadata for the JOSS application (i.e. fields that need updating in the JOSS database) once a paper is accepted.
In the future, this method should:
- Update the database fields automatically on the JOSS application.
- Deposit the Crossref XML to the Crossref API
$ whedon deposit {id}
# Ruby API equivalent
>> require 'whedon'
>> review = Whedon::Review.new(issue_id)
>> processor = Whedon::Processor.new(issue_id, review.issue_body)
>> processor.set_paper(path_to_paper.md_file)
>> processor.deposit