Reworking and exposing siunitx internals

I’ve been talking for a while about working on a new major version of siunitx. I’ve got plans to add some new features which are difficult or impossible to deliver using the v2 set up, but here I want to look at perhaps what’s more important: the back end, programming set up and related matters.

I’ve now made a start on the new code, working first on what I always think of as the core of siunitx: the unit processor. If you take a look at the new material and compare it with the existing release the first thing that should be obvious is that I’ve finally made a start on splitting everything up into different sub-parts. There are at least a couple of reasons for this. First, the monolithic .dtx for v2 is simply too big to work with comfortably. More importantly, though, the package contains a lot of different ideas and some of them are quite useful beyond my own work. To ensure that these are available to other people, it would seem best to make the boundaries clear, and separate sources helps with that.

That leads onto the bigger picture change that I’m aiming for. As regular readers will know, I wrote the first version of siunitx somewhat by accident and in an ad hoc fashion. Working on v2, I decided to make things more organised and also to use expl3, which I’d not really looked at before. So the process of writing the second version was something of a learning experience. At the same time, expl3 itself has firmed up a lot over the time I’ve been working with it. As such, the current release of siunitx has rather a lot of rough edges. In the new code, I’m working from a much firmer foundation in terms of conventions, coding ideas and testing implementations. So for v3 I’m aiming to do several things. A key one for prospective expl3 programmers is the idea of defined interfaces. Rather than making everything internal, this time I’m documenting code-level access to the system. That means doing some work to have clearly defined paths for information to pass between sub-modules, but that’s overall a good thing. I’m also using the LaTeX3 teams new testing suite, l3build, to start setting up proper code tests: these are already proving handy.

The net result of the work should be a better package for end users but also extremely solid code that can be used by other people. I’m also hopeful that the ideas will be usable with little change in a ‘pure’ LaTeX3 context. Documenting how things work might even have a knock-on effect in emulating siunitx in say MathJax. Beyond that, I’ve viewed siunitx as something of a sales pitch for expl3, and providing a really top-class piece of code is an important part of that. If I can get the code level documentation and interfaces up to the standard of the user level ones, and improve the user experience at the same time, I think I’ll be doing my job there.

6 thoughts on “Reworking and exposing siunitx internals

  1. Really interesting ideas, Joseph!

    Can you give a hint regarding probable backward compatibility issues between v2 and v3? (It’s somewhat easier for me to figure out how to deal with them if I have (a lot of) time to think about it.)

    Also, do you have an estimated release date for v3?

  2. I can only release a major update if I can work out enough of the compatibility issues. At the same time, there are a few things I think I will be aiming to change. What is certainly true is that I’ll have a very clear list of any changes before a release. At the present time, I’m anticipating very few out-and-out breakages.

    Currently, I can’t imagine having the code done before
    the end of the year. Particularly as there will need to be testing on everything that then probably means no release before some time in the first part of next year.

  3. Great to hear siunitx moving forward!
    However the v1 -> v2 transition was not whithout headache for me. Is there an option along the lines of:

    usepackage[version=2]{siunitx}

    I really think this is the only reasonable way to handle things and put it in the documentation that the end user should specify version upon import. (cf. documentation of mhchem)

  4. I’ve learned a lot since the v1 to v2 move! The reworking for v3 is complicated and uses a new approach to a lot of stuff. I’ve got a lot of testing to do yet to be comfortable I can provide back-compat. interfaces: it’s about a lot more than appearance settings. So at the moment what will happen I don’t quite know.

  5. Hi (again) Joseph.

    I hope the work on sunitx v3 is going according to plan. I’m just wondering if you have an idea of when the version might be ready?

    I am asking because I use your package in quite a lot of my documents and therefore it will probably take some time for me to make changes if all the code isn’t backwards compatible.

  6. The core unit formatting code is done but I have to sort out numbers and tabular material. I’d like to think it can be done some time in the summer this year. However, the problem I have is that I can’t release unless it is compatible with the current version or at least if the number of changes is very small and well-defined. So from a user point of view there will be no issue: I’m not abut to break existing document.

Leave a Reply