What is the best thing to do if you've inadvertently published a package which conflicts with another, where the conflict involves competing definitions of an environment?

In this case, both prooftrees and bussproofs define a prooftree environment. Hence, the packages cannot be loaded in the same document without modification.

The suggested solution at LaTeX for Logicians is to rename prooftrees.sty as tableaux.sty and then find-and-replace all occurrences of prooftrees by tableaux and all occurrences of prooftress by tableau. The tableau environment can then be used for prooftrees trees and prooftree for bussproofs trees.

However, I'm not convinced this is good advice. First, tableaux.sty will not get updated when prooftrees.sty does, so it makes maintenance tricky. Second, it will no doubt generate questions from users who will eventually forget that their tableaux.sty is really a (possibly outdated) copy of prooftrees.sty.

The user who reported the conflict suggested I rename prooftrees as tableaux and prooftree as tableau. But the existence of the tableaux package ruled out this name in the first place.

However, it does turn out that tableaux actually includes tableau.sty and not tableaux.sty, as I'd been assuming.

One way to workaround the issue at the document level is to add something like


to the preamble of the document. othername can then be used for prooftrees trees and prooftree for bussproofs trees.

One thing I could do, therefore, would be to include a tableaux.sty in prooftrees which loads prooftrees.sty and then does


so that users who say


can use tableau for prooftrees trees and prooftree for bussproofs trees.

This has obvious disadvantages: tableaux.sty will be provided by prooftrees rather than tableaux, while tableau.sty is provided by tableaux. Moreover, the tableau environment will also be provided by prooftrees rather than tableaux. However, I don't think this would produce a conflict with tableaux because tableau.sty provides neither tableau nor tableaux, as far as I can tell, and neither does minimum.sty, the other package file included in tableaux.

But the approach would also require users to load the packages in the correct order, as it won't work if people write


Or I could make tableaux.sty the main file and have prooftrees.sty load tableaux.sty and then


Or I could test at the end of the preamble whether prooftree is defined and make it an alias for tableau, if not.

But all of these options are messy and complicated. Moreover, I'm not sure if the above workaround is really safe or not.

In chat, barbara suggested just adding a workaround into the documentation. However, I wonder how many people will actually read that rather than turning to the net and creating a personalised tableaux.sty. On the other hand, maybe I am overstating the disadvantages of people doing this and this isn't such a bad workaround after all.

Of course, it would all be a lot easier if bussproofs defined bussproof rather than prooftree .... :(


I'd not try to be too fancy with detecting package order etc as it makes the behaviour hard to document.

I'd just have two package options prooftree and tableau and if either option is used then call the environment that.

if neither option is used then it's up to you what the default would be. You could default to tableau so avoiding a clash but make existing users add [prooftrees] if they do not want to change documents or make it default to [prooftrees] unless that environment is already defined in which case it defaults to [tableau] that would make the common case of just loading one package work as before, and the case of loading bussproofs then prooftrees avoid a clash.

that leaves loading bussproofs after prooftrees open to error but you could only avoid that by delaying everything to begin document so probably I wouldn't, just document that the user might need the tableau option or change the package order.

  • Thanks. I'm inclined to think this is the best option. However, egreg's suggestion would be more flexible. It just seems potentially more problematic/chaotic, I guess. Do you have a reason not to let users pick a name? – cfr Feb 7 '17 at 0:08
  • @cfr never give users choice:-) Not really any reason, Although it makes it harder perhaps to document or give examples as you will never know what the element is called or when users post disconnected fragments \begin{wibble}..\end{wibble} it will be harder to guess what package it came from. You see similar things with math alphabet packages which give a fixed choice of name of script font \euscr or \mathscr or \mathcal etc – David Carlisle Feb 7 '17 at 12:48
  • I can't really tell if you're serious or not ;). And isn't your solution more like the fixed-choice maths packages than egreg's? Or is that your point? – cfr Feb 7 '17 at 16:20
  • @cfr yes sorry that is what I meant. – David Carlisle Feb 7 '17 at 16:32
  • Actually, egreg's solution is the same. However, I think your answer was posted first. – cfr Feb 8 '17 at 23:41

In the options section, add


Then in the final part do


Thus a user wanting to use bussproofs can load


and use altprooftree in the document.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.