Difference between revisions of "CommunityData:Build papers"

From CommunityData
Jump to navigation Jump to search
(s/sharelatex/overleaf/)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
== Basic steps (quick and dirty version) ==
+
When creating LaTeX documents, the final PDF output must be built from an input file. For many of our projects, this process is even more complicated and we use [https://en.wikipedia.org/wiki/Makefile Makefiles] to manage more complex workflows. This document is intended to give an overview of the basic process and to identify good practices for quantitative projects.
  
# Export a bib file from Zotero into the directory where you're building your paper. Call the file <code>refs.bib</code>
+
== Project Creation ==
# The first time you're building the paper, you can just run <code>make</code> or <code>make all</code>. After that, you probably want to run <code>make clean; make all</code>. This should work whether you're using an .Rnw (knitter) or .tex (LaTeX) file.
 
  
=== ShareLatex adaptation ===
+
Follow the directions for installing the [[CommunityData:TeX|LaTeX templates]]. Once they are installed, you can run something like:
  
If you're using ShareLatex for your papers, that's great. The Best Practice is still to update the bibliography in Zotero, then export from there. Ideally, export into <code>refs.bib</code> and then upload that to ShareLatex so that the paper directory in our shared git repositories are up-to-date!
+
    cd ~/Projects
 +
    new_knitr_document project_name
 +
 
 +
This will create a new project called <code>project_name</code>.
 +
 
 +
This project will include a Makefile and all of the pieces needed to create a document.
 +
 
 +
== Zotero ==
 +
 
 +
The next step is to set up your references. Often, this means creating a new directory in Zotero. Follow the directions on the [[CommunityData:Zotero]] page. You should export your Zotero directory as Better BibLaTeX to the refs.bib file, and check "Keep updated" for Zotero to automatically update that file whenever the directory changes.
 +
 
 +
== Making the paper ==
 +
 
 +
# The first time you're building the paper, you can just run <code>make</code> or <code>make all</code>. After that, you probably want to run <code>make clean; make all</code>. This should work whether you're using an .Rtex (knitr) or .tex (LaTeX) file.
 +
 
 +
== Git ==
 +
 
 +
At this point, you should put your project into git. See [[CommunityData:Git]] for instructions.
 +
 
 +
 
 +
== Overleaf adaptation ==
 +
 
 +
If you're using Overleaf for your papers, that's great. The Best Practice is still to update the bibliography in Zotero, then export from there. Ideally, export into <code>refs.bib</code> and then upload that to Overleaf so that the paper directory in our shared git repositories are up-to-date!
  
 
== Style notes and more details (add as needed) ==
 
== Style notes and more details (add as needed) ==
  
* For sanity, it's good to create sub-directories within the paper directory to store things like knitr data and figures. For most of our existing projects these sub-directories have informative names like <code>knitter_data</code> and <code>figures</code>.
+
* The typical directory structure that I use is something like:
* Don't edit <code>refs-processed.bib</code> by hand. This is a file that the Makefile builds every time it compiles the paper. If you have some reason to edit the bibliography by hand, edit <code>refs.bib</code>, but do so at your own risk since collaborators and other Community Data folks may come by your repository and try to build the paper by downloading a new bib file from Zotero unless you tell them otherwise!
+
 
 +
    /code
 +
      01_script.py
 +
      02_script.py
 +
      03_analysis.R
 +
      README
 +
    /data
 +
      /raw_data
 +
        raw_data_file.csv
 +
      measures.csv
 +
      analyzed_data.RData
 +
    /paper
 +
      /data
 +
        analyzed_data.RData (symlinked)
 +
      /figures (any figures not created with knitr)
 +
      paper.Rtex
 +
 
 +
The code all lives in one place, with a README that explains what the pieces do. Don't underestimate the importance of a README and well-commented code. Your future self will thank you.
 +
 
 +
The data lives in another place, with raw_data which is read-only (and may or may not be stored in git, depending on the size). This raw data is used to create measures (and possibly some intermediate files). Analysis is done on the measures file, and stored in an RData file.
 +
 
 +
It is tempting to put as much of the analysis workflow as possible into the .Rtex file but these files can quickly become difficult to compile and unwieldy. It's often better to do the heavy lifting in a separate script, import an .RData file in the paper, and do things like creating plots and running simple statistical tests in the paper itself.
 +
 
 +
* You may need to use [https://tex.stackexchange.com/questions/25701/bibtex-vs-biber-and-biblatex-vs-natbib natbib] for some journal submission styles. The stackexchange page linked above helps to explain how to do that (but if anyone wants to give more detailed instructions, please do!).

Latest revision as of 13:58, 8 August 2019

When creating LaTeX documents, the final PDF output must be built from an input file. For many of our projects, this process is even more complicated and we use Makefiles to manage more complex workflows. This document is intended to give an overview of the basic process and to identify good practices for quantitative projects.

Project Creation[edit]

Follow the directions for installing the LaTeX templates. Once they are installed, you can run something like:

   cd ~/Projects
   new_knitr_document project_name

This will create a new project called project_name.

This project will include a Makefile and all of the pieces needed to create a document.

Zotero[edit]

The next step is to set up your references. Often, this means creating a new directory in Zotero. Follow the directions on the CommunityData:Zotero page. You should export your Zotero directory as Better BibLaTeX to the refs.bib file, and check "Keep updated" for Zotero to automatically update that file whenever the directory changes.

Making the paper[edit]

  1. The first time you're building the paper, you can just run make or make all. After that, you probably want to run make clean; make all. This should work whether you're using an .Rtex (knitr) or .tex (LaTeX) file.

Git[edit]

At this point, you should put your project into git. See CommunityData:Git for instructions.


Overleaf adaptation[edit]

If you're using Overleaf for your papers, that's great. The Best Practice is still to update the bibliography in Zotero, then export from there. Ideally, export into refs.bib and then upload that to Overleaf so that the paper directory in our shared git repositories are up-to-date!

Style notes and more details (add as needed)[edit]

  • The typical directory structure that I use is something like:
   /code
     01_script.py
     02_script.py
     03_analysis.R
     README
   /data
     /raw_data
       raw_data_file.csv
     measures.csv
     analyzed_data.RData
   /paper
     /data
       analyzed_data.RData (symlinked)
     /figures (any figures not created with knitr)
     paper.Rtex

The code all lives in one place, with a README that explains what the pieces do. Don't underestimate the importance of a README and well-commented code. Your future self will thank you.

The data lives in another place, with raw_data which is read-only (and may or may not be stored in git, depending on the size). This raw data is used to create measures (and possibly some intermediate files). Analysis is done on the measures file, and stored in an RData file.

It is tempting to put as much of the analysis workflow as possible into the .Rtex file but these files can quickly become difficult to compile and unwieldy. It's often better to do the heavy lifting in a separate script, import an .RData file in the paper, and do things like creating plots and running simple statistical tests in the paper itself.

  • You may need to use natbib for some journal submission styles. The stackexchange page linked above helps to explain how to do that (but if anyone wants to give more detailed instructions, please do!).