Giter Club home page Giter Club logo

mnogootex's Introduction

Многоꙮтех

CI tests status badge Latest release badge License badge Maintainability badge Test coverage badge

Многоꙮтех (mnogootex) is a utility that parallelizes compilation of a LaTeX document using different classes and offers a meaningfully filtered output.

The motivating use case is maintaining a single preamble while submitting a paper to many journals using their outdated or crummy document classes.

Getting started

Prerequisites

Многоꙮтех is written in Ruby and requires version >=2.5 (earlier ones are untested). You can check whether it's installed by running ruby --version. For installation instructions you can refer to the official documentation.

Многоꙮтех heavily relies on latexmk. You can check whether it's installed by running latexmk --version. If you are missing it, follow the documentation of your specific LaTeX distribution and install the latexmk package.

Installation

To install многоꙮтех execute

gem install mnogootex

If you're upgrading from a previous version, execute

gem update mnogootex

and remove any mention of mnogootex from your shell profile (it's not needed anymore).

Quick start

First you write a LaTeX document:

% ~/demo/main.tex
\documentclass{scrarticle}
\begin{document}
  \abstract{Simply put, my article is awesome.}
  Let's port my \KOMAScript\ article to other classes!
\end{document}

Then you list the desided classes in a Многоꙮтех configuration file:

# ~/demo/.mnogootexrc
jobs:
  - scrartcl
  - article
  - book

Finally you run mnogootex build and enjoy the technicolor:

A user types mnogootex build main.tex in the console. Some spinners indicating progress appear. Then the outcome for each class is presented. Failing ones include abridged and color coded logs, to pinpoint the errors.

Usage

A Многоꙮтех run does the following:

  1. copy the source folder of a project to many target folders, one for each job;
  2. replace the document class in the source of each target folder with the name of the relative job;
  3. call latexmk in parallel on each target folder to compile the documents (or do other tasks);
  4. wait for the outcomes and print the logs, filtered and colour-coded in a meaningful way.

Its convenience lies in the fact that it

  • automates the setup process,
  • parallelizes compilation,
  • improves the readability of the infamous waterfall logs.

Многоꙮтех can be invoked from CLI using mnogootex. It accepts various commands detailed below.

To leverage the full power of this tool you will need to learn writing mnogootex configurations and 'latexmk' configurations. It might sound daunting but they're really just a few lines.

mnogootex commands

Notation: [FOO] means that FOO is optional while FOO ... means one or more FOOs.

All commands except help accept the same parameters, so let's examine them in advance to avoid repeating ourselves later. Here is their syntax:

mnogootex COMMAND [JOB ...] [FLAG ...] ROOT

JOBs are the names of the document classes to compile your document with. Zero or more can be provided, and when none is given the job list is loaded from the configuration.

FLAGs are latexmk options. Zero or more can be provided to override the behaviour of the latexmk call underlying the mnogootex command. You can obtain a list of available options with the inline help latexmk --help, and the full documentation with man latexmk. Generally speaking, if you find yourself always using a FLAG you should properly configure latexmk instead.

The last mandatory parameter is the ROOT file for compiling of your document.

Let's examine the details of each command now.

help [COMMAND]

This command prints the help for COMMAND (or all commands if none is given).

exec [JOB ...] [FLAG ...] ROOT

This command simply runs latexmk on the ROOT document for each of your JOBs passing the given FLAGs.

All other commands below are specializations of this one. However you'll seldom use it unless you're debugging.

build [JOB ...] [FLAG ...] ROOT

This command builds your document.

It is equivalent to exec [JOB ...] -interaction=nonstopmode ROOT.

You will probably need to pass some FLAGs (e.g. to use the correct engine) but it is not recommended: configure latexmk instead.

open [JOB ...] [FLAG ...] ROOT

This command opens the final compilation artifact (after running the build if necessary).

It is equivalent to exec [JOB ...] -pv -interaction=nonstopmode ROOT.

You might need to pass some FLAGs (e.g. to use the correct viewer) but it is not recommended: configure latexmk instead.

clean [JOB ...] [FLAG ...] ROOT

This command deletes all nonessential build files while keeping the compiled artifacts.

It is equivalent to exec [JOB ...] -c ROOT.

clobber [JOB ...] [FLAG ...] ROOT

This command deletes all nonessential build files including the compiled artifacts.

It is equivalent to exec [JOB ...] -C ROOT.

mnogootex configuration

mnogootex is configured through YAML files named .mnogootexrc put into your projects' root directory.

When mnogootex loads a configuration it also looks up for .mnogootexrc files in all parent directories to merge then together (from the shallowest to the deepest path). This means that e.g. you can keep a configuration file in your home folder and use it as a global configuration for all you projects, while overwriting only specific options in the configuration files of each one.

mnogootex currently accepts three options.

jobs

This option represents the JOBs to build your document (when none are given via CLI).

It must contain valid document class names, given as a list of strings.

By default there are no JOBs:

# Default value:
jobs: []

Here is a slightly more interesting example:

jobs:
  - scrartcl
  - article
  - book

work_path

This option is the folder where all elaboration happens.

It must be a well formed path, given as a string.

By default none is given, meaning that each run of any given job happens in a dedicated temporary folder:

# Default value:
work_path: null

Overriding this allows you to have easier access to the compilation artifacts. A good choice is setting it to ./build and keep everything below your source folder:

work_path: ./build

spinner

This option is the spinner animation shown by the CLI.

It is a series of frames given as characters of a string.

By default it's a hole looping around in a blister:

# Default value:
spinner: ⣾⣽⣻⢿⡿⣟⣯⣷

Here is a couple more in case your terminal doesn't like Unicode:

# A wriggly ASCII worm:
spinner: )}]|[{({[|]}
# An extended ASCII boomerang:
spinner: ╒┍┌┎╓╖┒┐┑╕╛┙┘┚╜╙┖└┕╘

Feel free to get creative!

latexmk configuration

latexmk is configured through Perl files named .latexmkrc put into your projects' root directory.

When latexmk loads a configuration it also looks up for .latexmkrc files in all parent directories to merge then together (from the shallowest to the deepest path). This means that e.g. you can keep a configuration file in your home folder and use it as a global configuration for all you projects, while overwriting only specific options in the configuration files of each one.

latexmk has a gazillion of options. We'll just skim over the most common ones here.

First of all, one must pick the correct engine. Assuming you want to produce a PDF artifact, you have a few choices:

$pdf_mode = 1; # create PDF with pdflatex
# $pdf_mode = 2; # create PDF with ps2pdf (via PS)
# $pdf_mode = 3; # create PDF with dvipdf (via DVI)
# $pdf_mode = 4; # create PDF with lualatex
# $pdf_mode = 5; # create PDF with xelatex

Then, if your PDF previewer is not being detected, you might need to configure it. Assuming you want to use evince:

$pdf_previewer = 'start evince';

Most people won't probably need anything more than that. However, for further details read the documentation in the commandline with man latexmk or on CTAN

Acknowledgements

mnogootex's People

Contributors

paolobrasolin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

mnogootex's Issues

CLI hangs up when running `-pv`

Is there an existing issue for this?

  • I have searched the existing issues

Current behaviour

The preview command freezes mnogootex until the spawned processes are closed.

Expected behaviour

The spinners should spin, logs should be parsed and the outcome should be printed.
Then, the shell should immediately be back to prompt.

Steps to reproduce

It's sufficient to run

mnogootex exec article -pv main.tex

Additional context

No response

Support watch mode

Is there an existing issue for this?

  • I have searched the existing issues

Original problem

I'm tired of constantly relaunching the build command.

Proposed solution

It'd be nice to have a mnogootex watch which works by maintaining many parallel latexmk -pvc, showing spinners and filtered output.

Alternatives considered

No response

Additional context

No response

unwanted .git folders appear in each build subfolder2

├── build
│   ├── amsart
│   │   ├── bib
│   │   │   ├── allofthem.bib
│   │   │   └── .git
│   │   ├── eptcs.cls
│   │   ├── fouche
│   │   │   ├── act-fouche.sty
│   │   │   ├── fouche.sty
│   │   │   ├── .git              <- this .git is desirable, because "/fouche" is a submodule
│   │   │   ├── .gitignore
│   │   │   ├── .gitmodules
│   │   │   └── lipics-fouche.sty
│   │   ├── Gemfile
│   │   ├── Gemfile.lock
│   │   ├── .git                  <- this is unwanted.
│   │   │   ├── branches
│   │   │   ├── config
│   │   │   ├── ...

(Note: the issue might be solved by just .gitignoreing the /build directory)

Drop shell integration

mnogoo cd

Currently there's a command mnogootex dir which gives you the target folder (or the original path when you're in the target folder).
In turn, this is used to implement mnogoo cd which gets you back and forth between the two.

All this is implemented with a shell helper and symlink juggling.
That really feels like overkill since the feature is barely used.

I think we can safely drop this feature.

If we keep mnogootex dir then cd $(mnogootex dir) and cd - have basicaly the same function.

mnogoo open

Currently there's a command mnogootex pdf which gives you the path of the compiled artifacts.
In turn, this is used to implement mnogoo open which opens them with your system viewer.

We can safely remove this as it can be implemented leveraging latexmk -pv.

Enable test coverage reporting to Code Climate in GH

For reference, here is the old TravisCI configuration:

language: ruby
cache: bundler
rvm:
  - 2.5
  - 2.4
  - 2.3
env:
  global:
    - CC_TEST_REPORTER_ID=890ed5ee01002c7149920883256f8e4790000127faa9ddf14d86dd3ceb3b8179
sudo: false
before_install: gem install bundler --no-doc
before_script:
  - curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 > ./cc-test-reporter
  - chmod +x ./cc-test-reporter
  - ./cc-test-reporter before-build
script:
  - COVERAGE=true bundle exec rake spec:rspec
after_script:
  - ./cc-test-reporter after-build --exit-code $TRAVIS_TEST_RESULT
branches:
  only:
  - master

Minimize `mnogootex.yml`

We're undergoing a general redesign to leverage latexmk more.

Currently the options are

spinner: ⣾⣽⣻⢿⡿⣟⣯⣷
commandline:
  - latexmk
  - -pdf
  - --interaction=nonstopmode
work_path: null

spinner is merely aesthetics and can be dropped safely.

commandline can be avoided: we will assume only latexmk is being used, and we can configure it via .latexmkrc while forcing only the interactionmode if building.

work_path could be fixed to something like ./mnogootex in the documents root folder: not only it's simpler, but it guarantees the correct inheritance of .latexmkrcs which otherwise we wouldn't have.

So, we need to hardcode

  • the spinner
  • the commandline
  • the work path

Implement `mnogootex exec`

Implementing a completely generic command for parallel calls to latexmk will simplify #3 and #9.

The syntax should be

mnogootex exec [JOBS ...]  [latexmk_options] [filename ...]

in accordance to

Latexmk 4.75: Automatic LaTeX document generation routine

Usage: latexmk [latexmk_options] [filename ...]

The general behaviour and CLI feedback should be the same as mnogootex go.

Redesign CLI behaviour

The job and main parameters of the CLI are not really optional. We should either

  • improve help/documentaion, or
  • implement a better behaviour.

Some points to think about:

  • the cli parameter/flags should be equivalent to configuration files
  • I think a better order for the parameters exists

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.