5

If I give a LaTeX project using biber to colleagues (maybe working on another platform) I often get the feedback that the biber part caused problems (for example because of version issues).

Whats the best way to deal with this problem? Maybe there is a way to include the correct biber version or something like that.

9
  • Do your colleagues compile from scratch or do you distribute auxiliary files generated by biber with the project?
    – TeXnician
    Jun 28, 2018 at 20:02
  • 3
    Distributing Biber with your project would mean that you would also have to distribute biblatex since the versions of the two must be compatible. Distributing biblatex can easily mean distributing roughly 100 files (OK, you can probably reduce that if you only distribute the styles you need, at which point you might be violating the LPPL, but that might not be a big deal for you). But then biblatex has further dependencies - it is unlikely that you will have to distribute those as well: either the package has been stable for years ...
    – moewe
    Jun 28, 2018 at 20:11
  • 1
    ... or the functions that biblatex needs have been with the package for quite some years now, but you never know. Distributing biblatex with the project might be inconvenient because you will need to make sure that LaTeX uses 'your' biblatex over the system version - that either means modifying environment variables, using command line options, or dumping the entire tree flat into the document directory. Neither options sounds great to me.
    – moewe
    Jun 28, 2018 at 20:11
  • 2
    If you distribute temporary files, your colleagues may run into version troubles if they try to compile the document with your temporary files. If you don't distribute temporary files, they should normally be fine provided that their system has matching versions of biblatex and Biber and they manage to run Biber instead of BibTeX. And provided your document doesn't use fancy features that are not yet available for them.
    – moewe
    Jun 28, 2018 at 20:17
  • 3
    I wanted to say the same as moewe said: Just distribute a plain version and do not use too recent features. Then you should be fine given that your colleagues have a working biber setup in general (which is also hard sometimes).
    – TeXnician
    Jun 28, 2018 at 20:26

1 Answer 1

7

Distributing Biber also means distributing biblatex

If you want to distribute Biber with your project you must invariably also distribute biblatex, because the versions of the two must match.

Distributing biblatex might mean distributing ...

The current biblatex version 3.11 also relies on babel being not older than 2016-04-23 (v 3.9r), and loads xstring from at least 2013-10-13 (v1.7c) and etoolbox from at least 2010-11-29 (v2.1).

Additionally, biblatex loads pdftexcmds, keyval (last updated in 2014), kvoptions (last updated in 2016, only doc changes according to the change history), logreq, ifthen (last updated in 2014), url (last updated in 2013). Most of these should probably be fine even in older versions, but I think I remember one of the key-value packages changing something that led to a problem with biblatex...

Versions of polyglossia older than 1.42.0 (August 2015) could also be problematic, but then biblatex's polyglossia support is not great anyway and I would recommend to stick with babel if at all possible (see also the first part of my answer to \DeclareLanguageMappingSuffix, inheritance, and polyglossia in biblatex).

So depending on how ancient your colleague's systems are you may have to distribute additional packages if you distribute biblatex. From the survey above babel is a really realistic candidate, most other packages are probably fine. Keep in mind that all other packages you distribute might also have additional version dependencies.

Installation and use of the distributed versions

Even distributing biblatex is a bit of a complicated matter since the core together with the standard styles and localisation files weighs in at roughly one hundred files. You might try to cut down the number of files you distribute by only bundling the style files you need (I won't be using debug.bbx, so why should I ship it?), but that would probably (IANAL) violate the license conditions of the LPPL (that might not be a big deal for a private project, it becomes more problematic when the project is publicly available; in any way it demonstrates that you would go against best practices).

Furthermore, your colleague's systems would have to find your version of Biber and biblatex. That means that you either need your colleagues to install your versions manually system-wide (or lets say semi-manually if you give them a script to do it), which is in general not recommended (and can have bad consequences if done incorrectly, for example if you write into a directory controlled by the TeX distribution updates might overwrite parts of your manual installation). Or you would have to mess with environment variables, command line include options, or put all files into the document folder. Neither of these options sounds particularly user-friendly or clean to me.


So what can you do?

If you do not distribute the temporary files of your project (especially .aux, .bbl, .bcf, ...) your colleagues should be fine and can compile your project provided

  1. they have biblatex and Biber installed in matching versions,
  2. they know how to run Biber instead of BibTeX
  3. the document does not use cutting edge features that requires everyone to have the newest biblatex versions.

Point 1 is usually not a problem on complete single-user installs. biblatex and Biber will have been installed with the system and if updates were performed (assuming your colleagues did not cherry-pick updates) biblatex and Biber were updated at the same time. Since biblatex and Biber usually go out to CTAN at the same time, they also arrive in TeX live and MikTeX at the same time (although there have been some troubles with that in the past).

Multi-user installations (especially MikTeX) can be problematic if biblatex and Biber were installed in different modes and updates are only done infrequently and in only one of the two modes.

It can also be problematic if your colleagues did not install a complete system and biblatex and Biber were installed on different dates without an update before the later installation. That could leave a system with versions that don't match.

The solution here is to ask your colleagues to make sure that biblatex and Biber are installed and then update their system properly and completely before they start to work on your paper. That sounds easy, but I am aware that that might be a huge ask: An update is always risky and people might be rightfully wary of updating before a deadline. On university or corporate hardware your colleagues might not even have the necessary rights to initiate an update. Lastly, the update must be complete (How do I update my TeX distribution?), for multi-user MikTeX that means that it should be run in both admin and user mode (at least twice because critical system updates are prioritised, see also How should one maintain and update a MiKTeX installation?), for TeX live users it might mean installing anew version of TeX live (Why does TeX Live "require" yearly updates?).

Point 2 should be covered by Biblatex with Biber: Configuring my editor to avoid undefined citations and a few minutes of your time in case one of your colleagues has questions about this.

Point 3 is not really an issue if your colleagues all have updated to the newest version. Otherwise you need to be aware of the fact that some things you might want to use were not available in earlier versions. You will probably be fine as long as you only use very high-level features. But if you begin to do some more serious stuff, a hard barrier is probably version 3.3 (March 2016, Biblatex 3.3 name formatting), for date handling 3.5 is relevant (September 2016), ...

Why this concern with temporary files?

Distributing the temporary files is usually more risky, because they were written by a particular version of biblatex/Biber and are only understood by that version. As soon as one of your colleagues runs a different version, things break - possibly with unhelpful messages. Since temporary files are meant to be regenerated, there is very little need to keep their format backwards compatible, see also Matching biblatex in two machines.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .