Add option to not change loading order but only warn if (user) load order conflicts with the rules

[jonasc]

Hi, even though I find the idea of this project intriguing, I do not want to trust the automatic loading order. What I would like to have is a warning like:

Package Order Warning: hyperref should be loaded BEFORE amsrefs

Since you are already maintaining a (structured) list of dependencies it should be fairly easy to do this? I would be happy to help even though I currently have not a lot of time.

[vermiculus]

Best solution would probably be an option to \LoadPackagesNow (or whatever it's called) with an option to only echo what it would do – essentially a dry run.

[jonasc]

I have not looked too much into the internals, especially whether this might exchange the order of unrelated packages s.t. \usepackage{a}\usepackage{b} might become \usepackage{b}\usepackage{a}. This would hinder the analysis of the package order.

My first idea would be more like:

• Hijack \usepackage but instead of only storing the argument(s) actually execute the original \usepackage
• As far as I have understood there is a dependency graph built up during \usepackage. If there is a conflict encountered, print it out.

I guess that this might be a lot more work to implement, so this could be the long-term option.

[mhelvens]

Not a bad idea. Indeed, this would probably be easy enough, at least conceptually. My only problem is the same as yours: lack of time. Also, I haven't LaTeXed for a while, so my brain is not currently in in that mode.

So here's the plan: The feature request stays open regardless, because it's a good idea. This week I'll play around a bit, and if it's an easy thing to add, I'll do so. Otherwise, this may have to go on the back burner.

[mhelvens]

As it turns out, my laptop is having problems even processing the existing LaTeX code of pkgloader for some reason. :-( Something about l3regex I think. So the truth is, adding the feature is probably not that hard. My problem is setting up a working LaTeX environment after a long time of not needing one.

That's why this may take a while to be implemented. Sorry.